Internet Engineering Task Force S. Chakravorty Internet-Draft J. Bush Expires: April 15, 2007 The MITRE Corporation J. Bound NAv6TF October 12, 2006 IPv6 Label Switching Architecture draft-chakravorty-6lsa-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet transmission technique that uses the IPv6 packet header Flow Label to establish IPv6-based label switched paths. The label switched paths, called 6LSPs, provide application and user specified routes for efficient transport of packets and as means for quality of Chakravorty, et al. Expires April 15, 2007 [Page 1] Internet-Draft IPv6 Label Switching Architecture October 2006 service (QoS) or other service delivery. Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses, the architecture provides potential memory and processing savings, the latter through significantly reduced address fetches for the low-powered, handheld devices. Although the label from the source is delivered to the destination unmodified as required for conformance to the basic tenet of the existing defintion of the 3-tuple flow, the intermediate network nodes in 6LSA are allowed to temporarily replace the original label with a label of local significance. This enables 6LSA flows to be hop-specific although session-based and as such a unique QoS delivery technique for bandwidth constrained media. 6LSA also enhances security since label generation and assignment algorithms can be modified periodically. Chakravorty, et al. Expires April 15, 2007 [Page 2] Internet-Draft IPv6 Label Switching Architecture October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Distinguishing Characteristics of 6LSA . . . . . . . . . . . . 8 5. Routing Versus Switching of IP Traffic . . . . . . . . . . . . 10 6. 6LSA Basic Components and Their Attributes . . . . . . . . . . 10 6.1. Label . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Forwarding Equivalence Class (FEC) . . . . . . . . . . . . 12 6.4. Labeled Packet . . . . . . . . . . . . . . . . . . . . . . 12 6.5. IPv6 Label Switching Router (6LSR) . . . . . . . . . . . . 13 6.6. Lead Packet . . . . . . . . . . . . . . . . . . . . . . . 13 6.7. Packet Identifier (PID) Field . . . . . . . . . . . . . . 13 6.8. Switching Table . . . . . . . . . . . . . . . . . . . . . 14 7. Attributes of Label Binding . . . . . . . . . . . . . . . . . 14 8. IPv6 Label Switched Path (6LSP) . . . . . . . . . . . . . . . 15 9. 6LSA Architectural Functionalities . . . . . . . . . . . . . . 18 10. Label Assignment . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Locally Generated Label Model . . . . . . . . . . . . . . 20 10.2. Distributed Label Model . . . . . . . . . . . . . . . . . 21 10.3. Reuse Label Model . . . . . . . . . . . . . . . . . . . . 22 11. Scope and Uniqueness of Labels . . . . . . . . . . . . . . . . 22 12. Label Retention Mode . . . . . . . . . . . . . . . . . . . . . 22 13. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 23 14. Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . 23 15. Label Swapping . . . . . . . . . . . . . . . . . . . . . . . . 23 16. Packet Processing Algorithms . . . . . . . . . . . . . . . . . 23 17. Fast Switching . . . . . . . . . . . . . . . . . . . . . . . . 24 18. FEC Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 24 19. Penultimate 6LSR Label Processing . . . . . . . . . . . . . . 24 20. Invalid Incoming Labels . . . . . . . . . . . . . . . . . . . 25 21. 6LSP Control: Ordered and Loose . . . . . . . . . . . . . . . 25 22. Flow Aggregation or Merging . . . . . . . . . . . . . . . . . 25 23. Route Selection . . . . . . . . . . . . . . . . . . . . . . . 26 24. Explicit Routing using Routing Header Extension . . . . . . . 26 25. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26. Label Encodings . . . . . . . . . . . . . . . . . . . . . . . 26 27. Anycast in 6LSA . . . . . . . . . . . . . . . . . . . . . . . 27 28. Multicast in 6LSA . . . . . . . . . . . . . . . . . . . . . . 27 29. Security Considerations . . . . . . . . . . . . . . . . . . . 27 30. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 28 31. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 28 32. Informative Referneces . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Chakravorty, et al. Expires April 15, 2007 [Page 3] Internet-Draft IPv6 Label Switching Architecture October 2006 1. Introduction Several approaches have been developed over the past decade to provide QoS in large networks. These include DiffServ, RSVP, MPLS, ATM, extensions to routing protocols, and proprietary mechanisms. Some of these techniques can also be applied to IPv6 transport but not directly. IPv6 offers strong features to enable QoS delivery, most significant among them are the Flow Label and the Routing Header extensions. The IPv6 Label Switching Architecture (6LSA) specified here enables fast switching using 20-bit labels instead of 128-bit IPv6 addresses and thereby provides memory and processing savings, the latter because address fetches for low-powered, handheld devices, which are mostly 32-bit architectures, could be up to four times as fast. The architecture allows temporary replacement of labels inserted by a source node with the proviso that the original labels are reinserted prior to the packet arriving at its destinaion. This document introduces an architectural framework for the use of IPv6 packet header Flow Labels for setting up labeled paths of local significance to provide QoS for flows that cannot be provided by a purely routed, connectionless approach. The 6LSA allows local label generation in a network node. It also allows a network management entity updating available label tables, across the network to reduce man-in-the-middle attacks. This local label generation coupled with dynamic labeling helps the 6LSA to provide the means for mobile nodes to set up labeled paths, automatically and/or manually, for end-to-end QoS delivery or of any other service delivery. Finally, if it can be determined that two or more flows are destined for the same network or non-6LSA domain, then flow merging can be effectively implemented. The advantages are: less state is maintained in each 6LSR and there is no need to differentiate between individual flows after the merge point. The egress 6LSR restores flow labels for individual flows, a route lookup for the lead packet of the "first" flow on a merged LSP is all that is required for non- ingress 6LSRs which results in significant processing savings. 2. Overview The IPv6 label switching mechanism makes use of the 20-bit Flow Label in the IPv6 header to assign flow IDs which are used for labeld paths, also called IPv6 label switched paths (6LSPs). The specification of IPv6 label is in conformance with RFC 3697 [1], IPv6 Chakravorty, et al. Expires April 15, 2007 [Page 4] Internet-Draft IPv6 Label Switching Architecture October 2006 Flow Label Specification, in which the use of Flow Label has been recommended for establishing different types of flows at the source nodes and packet classification in the intermediate nodes. The proposed mechanism of IPv6 label switching broadens the scope of the use of Flow Labels beyond its simple use for packet classification to its use of packet classification and forwarding. The labels assigned in the packet header along a path can be different from the original Flow Label, assigned by the source, and as such they are temporary labels with only per hop significance unless such significance is extended to multiple hops. The original Flow Label always replaces the temporary labels before the packet is forwarded to its destination. In a conventional router, the forwarding decision is independently made in each router as the packet travels from one router to the next. In each router, the packet header is analyzed using a network layer routing algorithm to find the best next-hop that is often the shortest distance to the next router. Since this forwarding in each router is "independent" of how the previous packet for the same destination was processed and forwarded, the routing is considered connectionless. As noted in RFC 3031 [2], MPLS Architecture, e. Rosen, et al, IP packet header contains significantly more information than is needed for the selection of the best next hop. The process specified in this document supports two functions: first, grouping of packets of similar flow requirements into a Forwarding Equivalence Class (FEC), and second, forwarding all packets belonging to an FEC along the same path including flow merginging when multiple flows have the same FEC characteristics or are destined for the same network. In 6LSA, the FEC may be encoded in the Flow Label field as a non-zero value, which is also called label in this document. The label is available in one of 3 ways: (1) locally generated, based on certain algorithm or policy, (2) in the incoming packet, as Flow Label from a source node, or (3) distributed, through a label distribution process. The assignment of packet(s) to an FEC is identified as a binding. Once the binding of a label is created and provided to an FEC, the forwarding policy of the packet may be represented through the label and is maintained at a minimum for the duration of the session. The selection of a label is based on the FEC which itself is based on one or more packet characteristics. What characteristics should be chosen for what FEC is an administrative, service or policy decision, or a combination thereof. Such a decision is meant to support certain traffic requirements, such as those based on DSCP code points, or those values encoded or configured into the Traffic Class Chakravorty, et al. Expires April 15, 2007 [Page 5] Internet-Draft IPv6 Label Switching Architecture October 2006 field of IPv6 packet headers, or requirements conveyed by the source or administrative entity by other means. This selection and encoding procedure is outside the scope of this specification. Selection of FEC may be a configurable parameter of the router, server, host or any other device that implements this specification of 6LSA. Several conceptual models for how to build and use the 6LSA labels are introduced in this document. The label space available to 6LSRs is between 1 and 2^20 yielding the ability to uniquely identify 1,048,575 6LSPs. This label space applies to each physical interface. Merging of flows on a single 6LSP is possible with the consequence that two or more flows are inseparable and indistinguishable inside a 6LSA domain from the merge point 6LSR to the egress or penultimate 6LSR. Merging of flows lessen the amount of state maintained within 6LSRs and look-up memory and processing. The 6LSA label supports the forwarding of packets belonging to the same flow (or group of flows) and FEC along an IPv6 Label Switched Path ( 6LSP). For the lead packet of each flow, traffic class, source and destination addresses, and possibly other special handling requirements conveyed by the source (e.g., by a control plane protocol) are examined for FEC identification and label selection. This decision process is independently carried out on each 6LSR transited by the lead packets across a 6LSR domain. Subsequent packets of the same flow (or a group of flows) typically do not go through the same process of label selection and assignment because the label binding to an FEC and egress interface have been cached. Though 6LSA modifies flow labels to switch packets, it also preserves and restores original flow labels prior to destination node delivery. Before each packet emerges from an ingress 6LSR on a 6LSP, the original (incoming) flow label is placed in an IPv6 hop-by-hop options header. An egress 6LSR restores the original flow label and removes the hop-by-hop options header before forwarding the packet to non-6LSR domains. Internal 6LSRs within 6LSA domains may ignore but must not modify the contents of the hop-by-hop options header that carries the orignial label. 3. Terminology This section provides a general overview of alphabetically arranged terms used in this document. Some of these terms are more precisely defined in the later sections of this document. Most definitions mirror those provided in RFC 3031 [2] and are applied to the 6LSA specification as appropriate for consistency. Chakravorty, et al. Expires April 15, 2007 [Page 6] Internet-Draft IPv6 Label Switching Architecture October 2006 6LSA a set of nodes that perform 6LSA routing and forwarding operations and are in one routing or administration domain 6LSA egress node 6LSA edge node in its role of handling traffic as the traffic leaves a 6LSA domain 6LSA ingress node 6LSA edge node in its role of handling traffic as the traffic enters a 6LSA domain 6LSP label switched path, a virtual path, through a pair or more 6LSRs 6LSR IPv6 label switching router that is capable of forwarding IPv6 packets based on FEC attributes destination node the node which is the destination of one or more packets FEC Forwarding Equivalent Class, collection of IP packets that receive the same forwarding treatment and are forwarded over the same 6LSP Forwarding Table a data structure maintained by each 6LSR that maps incoming IPv6 flow labels and source and destination addresses to outgoing labels and outgoing interfaces flow sequence of packets identified by the 3-tuple of source address, destination address and Flow Label Flow Label the 20-bit label in the IPv6 header used for identifying flows flow merge same as label merging (see below), when it is applied to flows label the IPv6 Flow Label which is carried in the IPv6 packet header which may represent the packet's FEC; in this document, the label typically implies Chakravorty, et al. Expires April 15, 2007 [Page 7] Internet-Draft IPv6 Label Switching Architecture October 2006 the label from the upstream 6LSR carried in the Flow Label field label merging the replacement of multiple incoming labels with a single outgoing label label swapping the forwarding operation of looking in the switching table (to determine the outgoing label, physical port, and other data handling information) and replacing the incoming label with the outgoing label (if different from the incoming label) lead packet the first packet in the flow that this node has received, not necessarily the first packet from the source NTL packet next-to-the-lead packet, the packet that arrives at a 6LSA node after the lead packet of the flow source node the node that is the source of one or more packets which all may be associated with a flow subsequent packet any packet that arrives at a 6LSA node after the NTL packet switching table forwarding table that comprises packet forwarding information 4. Distinguishing Characteristics of 6LSA The 6LSA characteristics justify its application wherever IPv6 is deployed and where QoS network performance or other service delivery is required or where other available packet forwarding mechanisms cannot deliver packet performance end-to-end. The following special characteristics of 6LSA are listed here in no particular order: o 6LSA technology offers a methodology for use of flow label in the IPv6 header which is as yet unused. Chakravorty, et al. Expires April 15, 2007 [Page 8] Internet-Draft IPv6 Label Switching Architecture October 2006 o IP Transparency End-to-End - By being a Layer 3 protocal and avoiding encapsulation (as in MPLS) or fragmentation (as in ATM) of IP, the 6LSA retains the IP transparency end-to-end and provides for peering in Layer 3. o No-Extraneous-Label-Binding Option - 6LSA offers the option to avoid the use of any extraneous labels (labels from other than Layer 3) and may avoid the need for label distribution across the network o No IPSec Constraints - 6LSA does not typically need to use the Layer 4 ports and therefore can be used with IPSec VPNs or other IPSec-based services. o Free of Layer 2 Overheads - Being a layer 3 packet forwarding solution, the 6LSA does not need a layer 2 packet fowarding mechanism such as ATM and as such 6LSA avoids ATM's framgmentation and reassembly delays and associated header overhead. It also avoids the need for added signaling and state machine mechanisms to provide ATM switched paths and ship-by-night capabilities. Additionally, being based on routing protocols (6LSRs peer in Layer 3), 6LSA tends to avoid the potential for O(N2) and O(N3) problems. o Deployment Ease - The 6LSA can be deployed over all layer 2 protocols such as Ethernet and PPP. There is no layer 2 interface limitation in 6LSA. o Flow Aggregation or Merging - 6LSA allows aggregation of flows or flow merging if two or more flows are destined for the same network or non-6LSA domain resulting in benefits of reduced state maintenance, memory usage and processing. o Extensive QoS Label Space - The 20-bit Flow Label in addition to the 8-bit Traffic Class field can provide a huge traffic classification space, both the fields may be used together in the 6LSA. (This is a subject for further work and documentation.) o Feature Visibility - All of the IPv6 packet header features are available whlie the packet is enroute to destination as such IPSec or similar packet encryption does not disable the delivery of QoS or other similar services that 6LSA can provide. o Transition to 6PE - During the transition from IPv4 to IPv6, the latter is generally deployed as network-islands surrounding IPv4/ MPLS core. The implementation of 6LSA in native IPv6 edge networks will greatly facilitate traffic engineering between the edge and the core by allowing 6LSA flow labels to be carried over to MPLS labels in the core if the FEC representation by the flow label is common in both domains, for example, if the label represents a given bandwidth, Chakravorty, et al. Expires April 15, 2007 [Page 9] Internet-Draft IPv6 Label Switching Architecture October 2006 say, OC-12. o Security Enhancement - Since 6LSA allows node-local generation of labels, such generation where adopted can be made totally random or periodically synchronized across the 6LSA domain to considerably reduce man-in-the-middle attacks. To summarize, 6LSA provides a significant layer 3 mechanism for switching IP packets - with little or no added overhead for signaling. 5. Routing Versus Switching of IP Traffic The routing of packets on the Internet has the following essential characteristics in addition to connectionless, non-sequential packet transport: 1) The paths are not dedicated virtual paths, and 2) There are generally no delivery or QoS guarantees - a single class of traffic is available. Switching of packets has the following basic characteristics: 1) The routing of packets is connection-oriented; the flow of packets comprises sequential packets, 2) The packets travel over dedicated, virtual paths or virtual circuits (VCs) which are either permanent or temporary, and 3) Switching is generally associated with certain delivery guarantees and traffic classification. The issues with switching are: * There are delays caused by VC setup time across the network. * There is a need for VC state maintenance. * IP address to VC translation latency is always present however small. * Potential is there for large resource wastage in case of a link or node failure in IP virtual network over switched network, for example IP over ATM that may cause N2 and N3 problems. 6. 6LSA Basic Components and Their Attributes In this section, we define the basic components and their attributes pertaining to 6LSA. Chakravorty, et al. Expires April 15, 2007 [Page 10] Internet-Draft IPv6 Label Switching Architecture October 2006 6.1. Label A label is the 20-bit, fixed length Flow Label identifier in the IPv6 header. A node in the 6LSA binds the Flow Label to a Forwarding Equivalency Class (FEC) and uses it to forward the packet. The label may thus represent the FEC. In the 6LSA, the FEC indicates the forwarding treatment a group or class of packets (with a given label) receives. This label and the FEC it represents have only local (per hop) significance unless the attributes associated with a FEC are shared among multiple hops. A label in an incoming packet is called an "incoming label", and that in an outgoing packet is called an "outgoing label". A label is associated with both the flow and FEC. A flow cannot be identified without a label; the forwarding treatment associated with a FEC may be identified by the value of the label. In this document, the nomenclature of label or Flow Label is variously used though the meaning is the same and while referring to the word label used in other technologies, such as in MPLS, the context of the technology is also mentioned to distinguish the application and meaning of the word. 6.2. Flow A flow is a sequence of packets sent from a particular source node to a particular unicast, anycast or multicast destination node for which their special handling by the intervening nodes is desired. The nature of that special handling might be conveyed to the routers by a control protocol, such as the resource reservation protocol (RSVP), Differentiated Services Traffic Engineering (DSTE) mechanism, or by information within the flow's packets themselves. A flow is identifed by the label value in the Flow Label field in the IPv6 packet header. All packets belonging to the same flow must be sent with the same Flow Label from the source node to the destination node. The label in the lead packet and that in the subsequent packets of a flow may be different or the same depending upon the algorithm selected. In 6LSA domain, non-zero labels are also used for identifying a flow. Further applicable statements are quoted here from RFC 2460 [3] for clarity. A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. Chakravorty, et al. Expires April 15, 2007 [Page 11] Internet-Draft IPv6 Label Switching Architecture October 2006 A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. The 6LSRs or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 packet). The maximum lifetime of any flow-handling state established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup Hop-by-Hop Option. A source must not re- use a flow label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that flow label. 6.3. Forwarding Equivalence Class (FEC) The Forwarding Equivalence Class (FEC) represents a group of IPv6 packetws that all receive the same forwarding treatment. The forwarding treatment may be based on one or more attributes associated with the flow or other processing requirements imposed on the flow externally. Several flows from multiple sources may receive the same forwarding treatment and thus belong to the same FEC. For example, if multiple flows are to be processed in the same outgoing queue because they all deliver the same QoS, they are identified by the same FEC. 6.4. Labeled Packet In 6LSA, a packet that has a label value that a node can bind to a FEC is called a labeled packet. A labeled packet is an IPv6 packet whose header has a non-zero Flow Label value. If an incoming packet into a 6LSA node has a zero label value and it is not a lead packet, it is assigned a non-zero label value before it is forwarded. This is because in 6LSA, a zero label is used to indicate that the packet is a best-effort packet. The label from a flow in the 6LSA may be transferred to a non-6LSA network layer or to a non-6LSA data link layer as long as there is a field available that can carry the 6LSA label. The particular Chakravorty, et al. Expires April 15, 2007 [Page 12] Internet-Draft IPv6 Label Switching Architecture October 2006 encoding technique and its significance must be agreed by both the layers - layer 3, the network layer, and layer 2, the data link layer. Specifics of the method of this encoding are outside the scope of this document. 6.5. IPv6 Label Switching Router (6LSR) A router operating in the 6LSA is an IPv6 label switching router, called 6LSR, which performs as a minimum the two 6LSA functions of: 1) replacing (swapping) an incoming label in a packet with an outgoing label, and 2) forwarding the packet based on the appropriate forwarding treatment. A 6LSR is so called in this specification because other protocols, such as the MPLS, identify a label switching router as an LSR which has different capabilities. This helps avoid ambiguity with the definition of LSR. A 6LSR is either an upstream 6LSR or downstream 6LSR. The relationship means that with respect to a given label binding, a particular label represents a specific FEC for packets traveling out of an upstream 6LSR, into a next-hop node or 6LSR, or into a downstream 6LSR from a previous-hop node or 6LSR. 6.6. Lead Packet A packet arriving at a 6LSA node is a lead packet if it is the first packet of the flow that this node has received. A lead packet may or may not be the first packet of the flow that the upstream router or 6LSR forwarded to this 6LSR. It is possible that the first packet in the flow is lost or misdirected, or for that matter, first few packets in the flow are lost or misdirected. All lead packets, whether they are the first packet from the upstream router or 6LSR or not, are treated like they were the first packet of the flow. Lead packets have no existing entry in the switching table of the 6LSR. When source nodes are 6LSA nodes, lead packets may carry non- zero labels. 6.7. Packet Identifier (PID) Field An identifier, called Packet Identifier (PID) is a field in the switching table entry. The concept of switching table is later described in this specification (see the next Section). This field is updated whenever a packet is received by 6LSR. The PID value entered is 0 (zero), if the packet is identified as a lead packet, it Chakravorty, et al. Expires April 15, 2007 [Page 13] Internet-Draft IPv6 Label Switching Architecture October 2006 is 1 (one) if the packet is a NTL or subsequent packet, that is, it is not a lead packet. 6.8. Switching Table A switching table in 6SLA, often called the forwarding table in the networking literature. This table comprises the following information as they become available: -- Label value from the lead packet, if there is a non-zero label, otherwise a zero value is entered -- Packet Identifier (PID) Field value of 0 (zero) or 1 (one) -- Incoming interface, that is, interface on which the packet arrived -- Next hop IPv6 address -- Outgoing interface, that is, the interface on which the packet is forwarded to the next-hop 6LSR -- FEC value that identifies the forwarding operation that needs to be performed on a packet; this may include ordering and queuing of the packet prior to its transmission The outgoing label entered in the switching table has to be unique so that the 6LSR is able to identify a unique LSP for the packet. An exception would be when multiple LSPs are merged. This is discussed further in the following sections. Additional information that may be available in the switching table is as follows. * The data link layer and encapsulation to use * How the label value needs to be encoded in the label field * Timers associated with the packet * Last packet in the flow * Information with regard to how to discard labels or packets The format and content of the switching table entry are implementation and configuration specific and are not specified here. 7. Attributes of Label Binding The binding of a label to a FEC is based on known attributes of the packet or on externally applied constraints. The FEC may represent one or more of the following: Traffic Class, label value, source address, destination address, TCP/UDP port number, RTP value, one or more extension headers, special cookie marker in the packet, or Chakravorty, et al. Expires April 15, 2007 [Page 14] Internet-Draft IPv6 Label Switching Architecture October 2006 special bit encoding in the body of the message past the protocol headers. The FEC may also represent packet-forwarding parameters selected by the network administrator a-priori. For instance, if an attribute is a 1 Mbps bandwidth allocation to a flow then this allocation is taken care of in the forwarding treatment of the packet identified by the binding to the proper FEC. The binding of a label to a FEC is local to a 6LSR unless such binding is promulgated across the network through some exterior means such as a using a label distribution protocol (LDP) commonly used for MPLS. LDP is outside the scope of this document. The attributes of a label binding are configurable or encodable parameters in the 6LSA. The details of how the attributes are activated will be presented in a future traffic engineering specification. 8. IPv6 Label Switched Path (6LSP) A label switched path in the 6LSA is called 6LSP and identifies a virtual circuit through which one or more flows are routed to the next-hop 6LSR. While a flow has a local, per-hop significance, a 6LSP may have multiple-hop significance within the 6LSA. A 6LSP is identified with a sequence of 6LSAs, such that the following characteristics are applicable: -- R1, the ingress 6LSR, acquires a label and swaps it with the current label in packet P unless the the packet is a lead packet; -- For all values of i between 1 and n, there is only one label in each IPv6 packet, P, and this label value is encoded in the Flow Label field of P; -- At no time during transit of P through the network of 6LSRs within a 6LSP, if the label value is not bound to a FEC, the FEC can be a best-effort delivery FEC; -- For all i, where i has a value between 1 and n+1, Ri transmits P to R[i+1] by using the outgoing label in the packet (which is the same as the incoming label value in case of the lead packet); Chakravorty, et al. Expires April 15, 2007 [Page 15] Internet-Draft IPv6 Label Switching Architecture October 2006 -- For all i, between 1 and n inclusive, if a system S receives and forwards P after P is transmitted by Ri and before P is received by R[i+1], the forwarding decision that S makes is not based on the specifications applicable to 6LSA as identified in this document; such forwarding decision will imply that a layer 2 or other non-6LSA decision has been made outside the scope of this specification; -- Rn, the egress 6LSR, removes the incoming label and swaps it with the original label (that the ingress 6LSR received) and forwards the packet out based on the next-hop address, unless there is peultimate 6LSR label swapping, in which case, Rn may forward the packet based on the FEC but without binding the outgoing label to the FEC. The sequence of 6LSA nodes, that is, the sequence of nodal interfaces through which P is transported represents a 6LSP. A 6LSP is thus represented by a label between any two nodes, and by one or more sequence of labels between ingress and egress 6LSRs, or between two or more hosts, or any combination thereof. Conversely, a 6LSP may also represent the FEC binding of each flow in each of the 6LSR on the 6LSP. In this regard, 6LSP closely resembles a virtual circuit (VC) in ATM, and LSP in MPLS. A representative 6LSA layout is shown in Figure 1. In this layout, labels are encoded in the Flow Label field of the outgoing packets that are not lead packets, out of the ingress 6LSR, A, the intermediate 6LSR, B, and removed only at the egress 6LSRs, C, D and E when the flow of packets is from left ot right. The process is similar for the flows entering into the four border 6LSRs, A, C, D, and E in the opposite direction and for intermediate 6LSR. There can be many ingress, intermediate and egress 6LSRs in a 6LSA. Chakravorty, et al. Expires April 15, 2007 [Page 16] Internet-Draft IPv6 Label Switching Architecture October 2006 |L | +-+-+ | | +------------------+ D +---------------+ Non-6LSA | | | | domain | 6LSA +-+-+ | | domain | | | | | | |L2 (LSP) | | | | +-+-+ L1 (LSP) +-+-+ +-+-+ L | +----------------+ | | | ------+ | L2 (LSP) | | L6 (LSP) | | L ----> ------+ A +----------------+ B +-------------+ E +---> ------+ | L3 (LSP) | | | | | +----------------+ | | | +-+-+ +-+-+ +-+-+ | | | | |L2 (LSP) | | | | | | | | +-+-+ | | | | | +------------------+ C +---------------+ | | +-+-+ | |L Representation of 6LSPs inside a 6LSA Figure 1. Multiple 6LSPs may merge at a 6LSR if they can be identified with the same FEC and their outgoing route (6LSP) is the same in that they can terminate on the same next-hop 6LSR interface. If there are no other egress routers but E, in the representative configuration shown in Figure 2, the flows coming on three 6LSPs represented by L1, L2, and L3 into B could be merged and sent out on one 6LSP represented by L6. In this case, the flows maintain their identity by their source and destination addresses as well as by the original labels in the options header extension even if their outgoing labels are the same on 6LSP. This is also true of the lead packet flows where labels out of A would be all of 0 (zero) value. Chakravorty, et al. Expires April 15, 2007 [Page 17] Internet-Draft IPv6 Label Switching Architecture October 2006 +--------------------------------------+ Non-6LSA domain | | | 6LSA domain | | | | | | | +-+-+ L1 (LSP) +-+-+ +-+-+ L | +----------------+ | | | ------+ | L2 (LSP) | | L6 (LSP) | | L ------+ A +----------------+ B +-------------+ E +--- ------+ | L3 (LSP) | | | | | +----------------+ | | | +-+-+ +-+-+ +-+-+ | | | | +--------------------------------------+ Representation of 6LSPs inside a 6LSA Figure 2. Each 6LSP is maintained at least for the duration of the session of transport of all packets in a flow. In 6LSA, labels may be maintained for a pre-determined time after a session has ceased to exist, that is, for a fixed amount of time determined apriori after packets belonging to a flow have ceased to arrive. A 6LSP may extend all the way to the end-system if the end-system is operating within the 6LSA. 9. 6LSA Architectural Functionalities This section provides fundamental 6LSA functionalities including label acquiring, label binding to FEC, and label swapping. a) An ingress 6LSR replaces the incoming label in a non-lead packet with an outgoing label establishing a unique 6LSP for one or more packets in the flow, thus associating, with the same incoming Flow Label and source and destination address combination. Each ingress 6LSR ensures there is no duplication of 6LSPs from itself to the downstream router. Chakravorty, et al. Expires April 15, 2007 [Page 18] Internet-Draft IPv6 Label Switching Architecture October 2006 b) An intermediate router receives a flow on a unique 6LSP. c) An egress 6LSR replaces the incoming label with the label from the lead packet before forwarding the packet out to the destination node or a node belonging to a non-6LSA domain. d) To avoid the uncommon event when two flows entering a 6LSA domain from external sources have the same label, the Hop-by-Hop Options header is used (for all flows) to carry the original label and to identify the start of a new flow. The Hop-by-Hop Options header contains the original label in its Data field. A specific Option Type of 70 is used in the Hop-by-Hop Option header; the Option Data Length specified is 32. This 32-bit Option Data field contains the original 20-bit label from the lead packet with the left most 12 bits as 0 (zero). e) If a router is a 6LSR, it swaps the label, if it is not a 6LSR, it lets the flow bypass without any label changes. There are two salient points that need to be emphasized. First, the same label is not used for any two 6LSPs from an upstream 6LSR to a downstream 6LSR for the same pair of physical ports. Second, a label has little significance for the downstream 6LSR other than helping it ascertain the LSP assignment. It has relevance for the upstream 6LSR which uses it to bind an FEC to the label and then uses the 6LSP to forward packet. The 6LSP thus becomes a representation of the FEC and forwarding pointer for the upstream 6LSR. The only time a 6LSP and therefore the associated label has any relevance value to the downstream 6LSR is when the label bindings are distributed across a given 6LSA domain. The incoming flows into any of the nodes can arrive on one or more 6LSPs. If the outgoing flows are merged onto the same 6LSP, the downstream node receives the merged flow with the same label. Packets belonging to a merged flow although are from different flows but they each still need to be examined by its label. All merged flow's packets may have distinct source addresses and/or destination addresses, they all have original flow labels stored in the Hop-by- Hop Options header. However, once the flows are merged, distinction between individual flows may not be necessary for packet forwarding. Chakravorty, et al. Expires April 15, 2007 [Page 19] Internet-Draft IPv6 Label Switching Architecture October 2006 10. Label Assignment In the 6LSA, the decision to assign or bind a label to a particular FEC is made by a 6LSA node, generally by the ingress 6LSR if it is the origination point for that flow. The host or 6LSR node then informs the next-hop, downstream node of this binding via the labeled IPv6 packet that is transmitted or via some other method depending on the nature of label generation and distribution methodologies. Three models have been identified for acquiring label space. The first model specifies how the labels can be generated locally; the second model refers to how labels can be acquired from label distribution, and the third, how labels are acquired from incoming packet headers. Only one of these three models of label assignment is allowed in a network of 6LSA-based nodes. Once a label binding is available, the 6LSA requires that the label binding be retained for the duration of the session. It is quite possible that multiple flows may require the same label and label binding to a single FEC. In these cases, all such flows may be multiplexed or merged together as one outgoing flow and forwarded on one 6LSP using the same label. At the de-multiplexing 6LSA node downstream, the flows must be discernible through the unique source and destination addresses or through other means. The 6LSA does not prevent any 6LSA node from storing any label generated at a time different from when it is being used nor does it prevent a node from using any label that was used earlier or retrieved from a flow that used an algorithm or a model other than those identified here. 10.1. Locally Generated Label Model In this model, 6LSA allows a node to generate its own labels to be used in the IPv6 header. The specification for the algorithm(s) used to generate the 20-bit labels is beyond the scope of this document. An example algorithm for generating flow labels is a pseudorandom number generator outputting values within the parameters algorithm in which the bit values are within the parameters specified in Section 6.1, Label. It is envisioned that a set of labels will be generated for every service class, elastic and inelastic, such as file transfer, voice, video, etc. The Locally Generated Label model does not preclude manual generation of a label or range of labels through a configurator or similar other means. The locally generated label may have a value related to one or more attributes that is applicable to the next-hop 6LSR or nodes Chakravorty, et al. Expires April 15, 2007 [Page 20] Internet-Draft IPv6 Label Switching Architecture October 2006 across the network. The 6LSA specification allows labels that are locally generated but may have non-local significance. Such attributes may be regularly or randomly refreshed by a network management or other systems. Methodologies for such refreshment are outside the scope of this specification. This model is not a mandatory part of 6LSA, i.e., a node is not required to implement this model in order to be considered 6LSA- compliant. However, when a 6LSA node claims to implement the Locally Generated Label Model, the implementation must conform to the specification given in this document. This document encourages the use of this model because it is simple, efficient and avoids control plane traffic for label distribution as in the Distributed Label Model. The Locally Generated Label Model enhances security since the labels have local significance only and can be randomly or periodically refreshed all through the 6LSA domain prior to their use. To avoid duplication of labels between different flows while using this model, all lead and follow-on packets in a specific flow carry a unique label generated by the ingress 6LSR in the IPv6 Flow Label field. The Hop-by-Hop Options header is used by the ingress 6LSR to contain the original label which is placed in the Data field of the Hop-by-Hop Option header. A specific Option Type of 70 is used in the Hop-by-Hop Option header; the Option Data Length specified is 32. This 32-bit Option Data field contains the original 20-bit label from the lead packet with the left most 12 bits as 0 (zero). 10.2. Distributed Label Model The 6LSA allows distribution of label space generated in one or more nodes or externally in a server. The architecture also allows more than one label distribution protocol (LDP) and sharing of necessary information amongst the label distribution peers. Mechanisms or protocols that allow a 20-bit label distribution and do not violate any of the 6LSA specification with regard to use of such labels and the operation of 6LSA nodes are allowed. The specifics of label distribution protocols are outside the scope of this document. The process by which a node binds a label to a FEC are outside the scope of this document. The Distributed Label Model enhances security if the labels have local significance only and can be randomly or periodically refreshed all through the 6LSA domain prior to their use. Chakravorty, et al. Expires April 15, 2007 [Page 21] Internet-Draft IPv6 Label Switching Architecture October 2006 10.3. Reuse Label Model The 6LSA allows a node to reuse existing label available in the node or obtained from labels in the incoming packets and where the flows can be associated with unique label bindings. Details of this model remain to be developed for future specification. 11. Scope and Uniqueness of Labels A label in a packet on a 6LSP must be unique to a flow, in any given direction, between interfaces on peering nodes that are one hop apart. A flow always originates at the upstream source node in the 6LSA domain, continues through multiple 6LSRs and terminates in the destination node which also must exist in the 6LSA. Such a flow must carry a non-zero label in its lead packet. In the unusual event where two flows have lead packets with the same label, the follow-on labels used by the ingress routers are kept different for the two flows. In all 6LSR routers, the discriminator for these two lead packets is the physical port, source and destination address pair or such other means as allowed by the 6LSA implementer. To summarize, the discriminator for the incoming packets from an upstream 6LSR to this 6LSR is the 6LSP and the discriminator for the outgoing packets from this 6LSR to a downstream 6LSR is the FEC. Generally, for a flow, an incoming label represents the upstream 6LSP and an outgoing label represents the downstream FEC. In many cases, the same label may be usable or used for both. 12. Label Retention Mode If a 6LSR B receives a label binding from a 6LSR A for a particular FEC via LDP, even though B is more than one hop apart from A, then such binding may be retained or discarded by B. If the binding is retained, then this binding may be used later when A becomes a next- hop 6LSR to B. If the binding is discarded, then B will have to acquire a new binding for traffic from A through one of the three models described in Section 10. Chakravorty, et al. Expires April 15, 2007 [Page 22] Internet-Draft IPv6 Label Switching Architecture October 2006 13. Packet Forwarding Whatever the incoming label, unless the label carries some special significance because of certain bit arrangement in the label or some parameters associated with the label that were configured apriori, the forwarding treatment of the label is of local significance and decided by the 6LSA node itself. This treatment may or may not be the same the packet receives in any other node. The 6LSP chosen for the packet is thus based on the local FEC. The only exception to this rule may be a case when a label value is assigned globally, by policy, for example. So when a global label assignment is not used, that is, global label binding is not used, the 6LSP used for forwarding packet has significance only for the upstream 6LSR, the downstream 6LSR only associates the 6LSP with the label in the packet. The nature of the forwarding treatment and how it is applied is out of scope for this document. 14. Label Stacking The 6LSA does not allow IPv6 label stacking. There is only one label in an IPv6 packet and this label must be in the Flow Label field in the IPv6 packet header. The 6LSA allows multiple label spaces per platform, however, the use of the label must conform to the specifications stated in this document. It should be noted that this does not preclude other layer 3 non-IPv6 label stacking or layer 2 label stacking for VPNs or such other design. 15. Label Swapping Label swapping or label switching is a process in which the incoming label in a packet is replaced with an outgoing label. In this document, this process is associated with multiple other activities elaborated below. These activities include matching the switching table entries with certain incoming packet header fields, binding a label to the FEC, updating the switching table and finally, forwarding the packet. However, when the swapping involves only incoming label replacement with an outgoing label, it is called label switching, which typically is a fast process and may be carried out in the interface card itself. 16. Packet Processing Algorithms The 6LSA packet processing algorithm refers to handling of packets that arrive from hosts in the same 6LSA domain or from networks outside of the 6LSA domain. The 6LSA packet processing provides for Chakravorty, et al. Expires April 15, 2007 [Page 23] Internet-Draft IPv6 Label Switching Architecture October 2006 QoS priority handling and forwarding treatment. If the 6LSA domain is a network connected to one or more non-6LSA networks that insert labels not known to the 6LSA domain devices apriori, then the processing is called the Open Network Packet Processing. This approach can make full use of the Locally Generated label Model. If the 6LSA domain is not connected to any external network, such as would be the case of a closed campus network or a secure network, where duplication of labels can be avoided through extraneous means, for example, through grouping of labels across the network as referred to in the Distributed Label Model, then it is possible to use a different processing, called here the Closed Network Packet Processing. Open Network and Closed Network processing algorithms will be specified in future drafts. Other packet processing algorithms are also possible. 17. Fast Switching When a 6LSR can simply swap an incoming label with an outgoing label without going through insertion of new entry in the switching table for that packet, then this swapping is termed fast switching in this specification. 18. FEC Mapping Each FEC may map to a set of flows, node and route characteristics which may be represented in the switching table. The switching table may consist of more than one entry that a particular FEC can be mapped to and forwarded via a labeled packet. 19. Penultimate 6LSR Label Processing If the label in a non-lead packet is acquired through the Locally Generated Label model and not through other means and applied to a packet in the 6LSR upstream of the penultimate 6LSR, the latter being the 6LSR one hop upstream of the egress 6LSR, the penultimate 6LSR may decide to not bind the label to the FEC for this flow but simply insert it in the packet and forward the packet out since the next hop is not affected by the absence of any prior label binding. The egress 6LSR forwards the packet out based on the outgoing route. This saves processing related to binding at a minimum. Chakravorty, et al. Expires April 15, 2007 [Page 24] Internet-Draft IPv6 Label Switching Architecture October 2006 20. Invalid Incoming Labels An incoming or acquired label is invalid if it has a value that does not allow the 6LSA node to bind the label to a FEC. Such a label may be discarded after the lead packet is forwarded. Invalid labels may not include a zero-labeled packet. The discussion of the values of such labels are outside the scope of this specification. 21. 6LSP Control: Ordered and Loose As described in the MPLS label switching architecture [1], some FECs correspond to address prefixes which are available from dynamic routing algorithm running in a node. There are two methods in 6LSA for setting up LSPs for these FECs: Ordered and Loose. The control of 6LSP is a local function at a 6LSA node. In 6LSA, each FEC is identified with a set of attributes. If the traffic in a particular FEC has to follow the same path that has a specified set of attributes such as bandwidth and other resources (QoS parameters) etc., then ordered control must be used. How this ordered control is initiated and maintained is out of the scope of this document and is an area for further work. In the loose control, a 6LSR after binding a label to a FEC, distributes that binding to its label distribution peers more like the routing algorithms. Ordered control and loose control are fully interoperable. 22. Flow Aggregation or Merging If it can be determined that two or more flows are destined for the same network or non-6LSA domain, then flow merging are implemented. The advantages are: less state is maintained in each 6LSR and there is no need to differentiate between individual flows after the merge point. The egress 6LSRs will be able to restore flow labels for individual flows since the Hop-by-Hop Options header is independent of the label identifying the merged flow, and a route lookup for the lead packet of the "first" flow on a merged 6LSP is all that is required for non-ingress 6LSR's -- a big saving. The 6LSA allows aggregation of labels when FECs represent address prefixes. Since IPv6 address prefixes are aggregatable, aggregation of FECs corresponding to aggregatable prefixes is allowed in the 6LSA. The extent of aggregation is a function of the address aggregation, granularity of service desired or both. Such Chakravorty, et al. Expires April 15, 2007 [Page 25] Internet-Draft IPv6 Label Switching Architecture October 2006 aggregation may further be decided by the IPv6 packet header Traffic Class parameters. 23. Route Selection The method of selecting the proper 6LSP for a particular FEC is called route selection in the 6LSA and the options the 6LSA allows are (1) hop-by-hop routing, and (2) explicit routing. The Hop-by-Hop Option has been described above in Section 9 in which each node in the 6LSA independently selects the next hop based on a given FEC. This is very similar to the best-effort routing except that the forwarding in this mode of 6LSA is FEC driven. For explicit routing, see Section 24 here below. 24. Explicit Routing using Routing Header Extension To ensure explicit routing of packets, the 6LSA allows use of IPv6 Routing Header extensions. The Next Header value of 43 is then an attribute that a given FEC must include. In this case, the label binding to the FEC represents explicit routing using the Next Header value. The forwarding treatment a packet gets in a 6LSR comprises transmitting the packet to the next-hop 6LSR identified in the destination address field of the packet. The final destination of the packet in an explicitly routed packet may be outside of the 6LSA domain. 25. Control The 6LSA specification requires the Hop Limit value in the packet header be decremented by 1 (one) in each 6LSR. The 6LSA processing of Hop Limit remains the same as in conventional IPv6 packet processing. 26. Label Encodings The 6LSA allows encoding of the label value in layer 2 protocols such as in ATM packet's VPI/VCI fields. Since only one label is used and that each such label is uniquely identifiable in the 6LSA, encoding the label in the ATM VPI/VCI field is feasible. Considerations with respect to how flows are identified, the FEC-based forwarding treatment and flow merging issues need careful planning in the layer 2 label encoding. Chakravorty, et al. Expires April 15, 2007 [Page 26] Internet-Draft IPv6 Label Switching Architecture October 2006 How a 6LSA label value is encoded in the ATM VPI/VCI field is outside the scope of this document. 27. Anycast in 6LSA IPv6 defines the anycast address like a regular unicast address with a prefix specifying the subnet and an identifier that is set to all zeroes. Anycast packets delivered to this address are delivered to one router in that subnet. There are reserved subnet anycast addresses such as for mobile IPv6 Home-Agents anycast. The 6LSA allows the use of anycast addressing. Whenever a 6LSR is a node in any anycast subnet, such a subnet may be a 6LSA, a subset of 6LSA or some other part of 6LSA. When an anycast packet arrives in anycast subnet 6LSR where the subnet is a part or whole of 6SLA, the 6LSR binds the packet to a FEC which has anycast routing as part of the forwarding treatment attributes of the FEC. The packet is thus forwarded to a next-hop 6LSR through an interface determined by the FEC attributes related to anycast forwarding. 28. Multicast in 6LSA IPv6 defines the mutlicast address by the high-order octet FF or 11111111 in binary notation and 4 bits for the scope of the multicast and an identifier bit that indicates whether the multicast address belongs to a well-known IANA multicast address group or is a temporary address. The 6LSA allows the use of mutlicast addressing. A multicast tree may be a 6LSA, or a subset of 6LSA. For multicast transmission, the 6LSR binds the packet to a FEC which may represent mutlicast routing. The packet is thus forwarded to a next-hop 6LSR through an interface determined by the FEC attributes related to mutlicast delivery. 29. Security Considerations The 6SLA allows Security Association (SA). If the security association partners are outside the 6SLA, then there is no effect on the 6SLA by the SA whether the mode of operation is in the transport mode or in the tunnel mode. In the transport mode of SA, only the packet payload is subject to encryption or authentication, so the IPv6 packet header features are not affected and the 6LSA being a transport mechanism that sets up 6LSPs and provides specific FEC-driven forwarding treatment, there is no impact on the 6LSA or impact on SA operation by the 6SLA. Chakravorty, et al. Expires April 15, 2007 [Page 27] Internet-Draft IPv6 Label Switching Architecture October 2006 In the tunnel mode of SA, the SA requires an outer wrapper IPv6 packet. The sending gateway wraps the whole IPv6 packet including the content. The receiving gateway performs the checksum on the outer wrapper packet, unwraps the packet and then verifies the checksum of the inner packet through end-to-end SA. If the outer wrapper packet conveys the Flow Label value of the inner packet, then 6SLA provides the 6LSP transport based on the inner label value, otherwise the transport indicates the outer label value. Here also, there is no impact on the 6LSA based transport of the secure packets or vice versa. The Authentication Header (AH) is used in IPv6 for authentication of individual packets to prevent common Internet-based attacks such as IP address spoofing and session hijacking. The computation of cryptographically secure checksum over the payload as well as some fields of the IPv6 and extension headers has to take place between the SA partners. This computation does not include the Flow Label field in the packet header. This maintains label transparency in the 6SLA. Authentication can be either in the transport mode or in the tunnel mode. The 6SLA security considerations that apply to Encrypted Security Payload (ESP) header comprise encryption modes that are categorized as transport mode or tunnel mode. In the transport mode, no encryption of the Flow Label field is performed, so the value is carried through the 6SLA. In the tunnel mode, the issues are the same as stated here above. 30. Acknowlegements The author deeply appreciates significant editing contributions made by Keith Scott (MITRE), and early implementation support provided by Don Chirieleison (MITRE). 31. Disclaimer Any affiliation the first two authors have with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the authors. 32. Informative Referneces [1] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. Chakravorty, et al. Expires April 15, 2007 [Page 28] Internet-Draft IPv6 Label Switching Architecture October 2006 [2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [7] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Chakravorty, et al. Expires April 15, 2007 [Page 29] Internet-Draft IPv6 Label Switching Architecture October 2006 Authors' Addresses Sham Chakravorty The MITRE Corporation 1575 Colshire Dr. McLean, VA 22102 USA Email: schakra@mitre.org Jeff Bush The MITRE Corporation 1575 Colshire Dr. McLean, VA 22102 USA Email: jbush@mitre.org Jim Bound NAv6TF PO Box 570 Hollis, NH 03049 USA Email: Jim.Bound@ipv6forum.com Chakravorty, et al. Expires April 15, 2007 [Page 30] Internet-Draft IPv6 Label Switching Architecture October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chakravorty, et al. Expires April 15, 2007 [Page 31]