|
Internet Drafts - IDs for Mar/2007
Index - Month Index of IDs
All IDs - sorted by date)
22/03/2007
| |
|
| |
| | IPv6 Dynamic Flow Label Switching (FLS) |
| |
|
This document seeks to establish a standard for the utilization of the Class of Service Field and the us of the Flow Label Field within the IPv6 Header and establish a methodology of switching packets through routers using the first 32-bits of the IPv6 header using Flow Label Switching on packets rather than full routing of packets. Within the first 32-bits of an IPv6 header exists the requisite information to allow for the immediate “switching” on an ingress packet of a router, allowing for “Label Switching” of a native IPv6 packet. This allows the establishment of VPN circuits in a dynamic manner across transit networks. The establishment of “Flows” based upon the 20-bit “Flow Label” value can be done dynamically with minimal effort and configuration of the end-point routers of the flow. The flows can be managed or open, encrypted or in the clear, and will allow for greater scalability, security, and agility in the management and operation of networks. |
09/03/2007
| |
|
| |
| | IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP) |
| |
|
This document outlines a methodology for IPv6 Header Compression via mapping the source and destination addresses into a flow label value per address pair sessions with a specific traffic class field value to identify the packet as “address-less” compressed header. The resultant headers, sans addresses shrink from 320 bits to 64 bits. This mapping is locally specific to the router port and the connecting hosts/router ports. Specifically written for use on low bandwidth links (less than T1 or 1.544Mbps), IPv6 AMP’s applicability goes to integration of cellular/WiFi appliances and will be critical for tactical uses for military and first responder applications. |
08/03/2007
| |
|
| |
| | Limited IP Header Compression over PPP |
| |
|
The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. [RFC3544] refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets (and also added Enhanced RTP-Compression negotiation option). The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. |
02/03/2007
| |
|
| |
| | Light Weight Access Point Protocol |
| |
|
In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. |
|
