Internet Engineering Task Force S. Chakravorty Internet-Draft The MITRE Corporation Expires: August 21, 2005 February 20, 2005 IPv6 Label Switching Architecture draft-chakravorty-6lsa-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 21, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 speedier transport of packets and as means for quality of service (QoS) or other service delivery. Through fast swapping of 20-bit labels instead of 128-bit IPv6 address look-ups, the Chakravorty Expires August 21, 2005 [Page 1] Internet-Draft IPv6 Label Switching Architecture February 2005 architecture also provides 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, conforming 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 disruption by man-in-the-middle attacks through label changes may not affect flows end-to-end but only over a single hop. 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 . . . . . . . . . . . 9 6. 6LSA Basic Components and Their Attributes . . . . . . . . . 10 6.1 Label . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3 Pseudoflow . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4 Forwarding Equivalence Class (FEC) . . . . . . . . . . . . 12 6.5 Labeled Packet . . . . . . . . . . . . . . . . . . . . . . 12 6.6 IPv6 Label Switching Router (6LSR) . . . . . . . . . . . . 13 6.7 Lead Packet . . . . . . . . . . . . . . . . . . . . . . . 13 6.8 Packet Identifier (PID) Field . . . . . . . . . . . . . . 14 6.9 Switching Table . . . . . . . . . . . . . . . . . . . . . 14 6.10 Attributes of Label Binding . . . . . . . . . . . . . . 15 6.11 IPv6 Label Switched Path (6LSP) . . . . . . . . . . . . 15 7. 6LSA Functionalities . . . . . . . . . . . . . . . . . . . . 18 7.1 Label Assignment . . . . . . . . . . . . . . . . . . . . . 18 7.1.1 Locally Generated Label Model . . . . . . . . . . . . 19 7.1.2 Distributed Label Model . . . . . . . . . . . . . . . 20 7.1.3 Reuse Label Model . . . . . . . . . . . . . . . . . . 20 7.2 Scope and Uniqueness of Labels . . . . . . . . . . . . . . 21 7.3 Label Retention Mode . . . . . . . . . . . . . . . . . . . 23 7.4 Packet Forwarding . . . . . . . . . . . . . . . . . . . . 24 7.5 Label Stacking . . . . . . . . . . . . . . . . . . . . . . 24 7.6 Label Swapping . . . . . . . . . . . . . . . . . . . . . . 24 7.7 Packet Processing Algorithm . . . . . . . . . . . . . . . 24 7.7.1 Packet Processing in Locally Generated Label Model . . 25 7.7.2 Packet Processing in Reuse Label Model . . . . . . . . 33 7.7.3 Packet Processing in the Distributed Label Model . . . 33 7.8 Fast Switching . . . . . . . . . . . . . . . . . . . . . . 33 7.9 FEC Mapping . . . . . . . . . . . . . . . . . . . . . . . 33 7.10 Penultimate 6LSR Label Processing . . . . . . . . . . . 33 Chakravorty Expires August 21, 2005 [Page 2] Internet-Draft IPv6 Label Switching Architecture February 2005 7.11 Invalid Incoming Labels . . . . . . . . . . . . . . . . 33 7.11.1 LSP Control: Ordered and Loose . . . . . . . . . . . 34 7.12 Aggregation . . . . . . . . . . . . . . . . . . . . . . 34 7.13 Route Selection . . . . . . . . . . . . . . . . . . . . 34 7.13.1 Hop-by-Hop Routing using Hop-by-Hop Header Extension . . . . . . . . . . . . . . . . . . . . . 35 7.13.2 Explicit Routing using Routing Header Extension . . 35 7.14 Control . . . . . . . . . . . . . . . . . . . . . . . . 35 7.15 Label Encodings . . . . . . . . . . . . . . . . . . . . 35 7.16 Anycast in 6LSA . . . . . . . . . . . . . . . . . . . . 35 7.17 Multicast in 6LSA . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . 36 9. Informative Referneces . . . . . . . . . . . . . . . . . . . 37 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . 37 11. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 38 12. Implementation Direction . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . 39 Chakravorty Expires August 21, 2005 [Page 3] Internet-Draft IPv6 Label Switching Architecture February 2005 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 of 20-bit labels instead of 128-bit IPv6 address look-ups and thereby provides memory and processing savings, the latter because address fetches for low-powered, handheld devices, which are mostly 32-bit architectures, would be four times as fast. 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 any associated network management entity to update label tables, across the network to reduce man-in-the-middle attacks. This local label generation coupled with dynamic labeling helps 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. 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 labeled paths, also called IPv6 label switched paths (6LSPs). The specification of IPv6 label is a limited variation of RFC 3697, IPv6 Flow Label Specification [1], 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 use for packet classification to packet forwarding. 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's 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 Chakravorty Expires August 21, 2005 [Page 4] Internet-Draft IPv6 Label Switching Architecture February 2005 for the same destination was processed and forwarded, the routing is considered connectionless. As noted in RFC 3031, MPLS Architecture, e. Rosen, et al, [2], the IP packet header contains significantly more information than is needed for the selection of the best next hop. The process specified in this document provides 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 or set of paths; the latter when multiple paths are allowed, for example, in case of load balancing. 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 the 3 ways: (1) in the incoming packet as Flow Label, (2) locally generated based on certain algorithm or policy, or (3) distributed through a label distribution process. The assignment of packet(s) to an FEC is called binding. Once a binding of a label to a given FEC is performed, the forwarding treatment of the packet may be represented through the label and is maintained at a minimum for the duration of the session. The label may be strictly local-node based (of local significance) as also the processing of the packet. Several models for how to build and use the 6LSA labels are presented in this document. The IP packet header, specifically the IPv6 packet header, contains more information than is needed to determine the next hop and to forward the packet. The 6LSA label can easily support the forwarding of packets belonging to the same FEC along a 6LSP. In the 6LSA, only the first packet of a flow is analyzed for FEC determination and label selection. Subsequent packets of the same flow may not need to go through the same process of label selection and assignment. Packet forwarding is done using the Flow Label only after the label binding to a FEC has taken place. At each router, the label assigned to a packet, along with the packet's source and destination addresses, and other processing criteria are entered into a packet forwarding table. The label is assigned to the lead packet of a flow, which may or may not be the same as first packet of the flow. As subsequent packets arrive, the forwarding table is checked using the algorithms described here to see if there is a label for the flow. If none exists, a label is Chakravorty Expires August 21, 2005 [Page 5] Internet-Draft IPv6 Label Switching Architecture February 2005 assigned to the packet and the packet is treated as a lead packet. If a label value exists in the forwarding table, then the packet is given the same forwarding treatment as the label binding indicates. Since the packet forwarding decision can be made based on a single table look up, the packet processing is fast, as per a known forwarding treatment, and takes place over a known path. The selection of a label is based on the FEC to which the label is bound. 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 service delivery requirements, such as those based on DSCP code points or other similar values encoded or configured into the Traffic Class field of IPv6 packet header. 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. Finally, 6LSA is applicable to any device that is capable of processing and forwarding IPv6 packets. This protocol is not constrained by any layer 2 or layer 1 technology. 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 of the definitions mirror those provided in RFC 3031 [2] and are applied to the 6LSA specification as appropriate for consistency. 6LSA a set of nodes that perform 6LSA routing and forwarding operations and are in one routing or administration domain 6LSA egress node LSA 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 a label switched path, a virtual path, through a pair or more 6LSRs 6LSR IPv6 label switching router that is Chakravorty Expires August 21, 2005 [Page 6] Internet-Draft IPv6 Label Switching Architecture February 2005 capable of forwarding IPv6 packets based on FEC attributes FEC Forwarding Equivalent Class; a collection of IP packets that receive the same forwarding treatment and are forwarded over the same 6LSP label the IPv6 Flow Label which is carried in the IPv6 packet header which may represent the packet's FEC flow a flow is a sequence of packets identified by the flow label and source and destination addresses 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 merging the replacement of multiple incoming labels with a single outgoing label label swapping the forwarding operation of looking up an incoming label (to determine the outgoing label, port, and other data handling information) and replacing the incoming label with the outgoing label (if different from the incoming label) lead packet a packet arriving at a 6LSA node that is the first packet in a flow that this node has received NTL packet next-to-the-lead packet, a packet that arrives at a 6LSA node after the lead packet of the flow pseudoflow a flow is identified by the Flow Label and may have the lead packet carrying a 0 (zero) label source node a node that is the source of one or more packets which all may be associated with a flow Chakravorty Expires August 21, 2005 [Page 7] Internet-Draft IPv6 Label Switching Architecture February 2005 subsequent packet any packet that arrives at a 6LSA node after the NTL packet of the flow 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 the use of flow label in the IPv6 header that provides accelerated packet forwarding and allows QoS and other service delivery. o IP Transparency End-to-End - By being a Layer 3 protocal and by 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 and may avoid the need for label distribution across the network o No IPSec Constraints - 6LSA does not need to use 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 and as such 6LSA avoids framgmentation and reassembly delays and associated header overhead as in the case of ATM. It also avoids the need for added signaling and state machine mechanisms to provide ATM-like 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 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.) Chakravorty Expires August 21, 2005 [Page 8] Internet-Draft IPv6 Label Switching Architecture February 2005 o Feature Visibility - All of IPv6 packet header features are available whlie the packet is enroute to destination so 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 being 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. 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 enhance security. o Hop Limit field - the 8-bit hop limit field in the IPv6 header is available for looping prevention. There is no need to port this value to another field or label. o No MTU Violation - since the packet size does not change without the use of extraneous labels, 6LSA eliminates the potential for MTU violations. To summarize, 6LSA provides a significantly efficient and powerful layer 3 mechanism for fowarding 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 best-effort service is available. Switching of packets has the following basic characteristics: 1) The routing of packets is connection-oriented; the flow of packets typically comprises sequential packets, 2) The packets travel over dedicated, virtual paths 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. Chakravorty Expires August 21, 2005 [Page 9] Internet-Draft IPv6 Label Switching Architecture February 2005 * There is the need for VC state maintenance. * IP address to VC translation latency is always present however small. 6. 6LSA Basic Components and Their Attributes In this section, we define the basic components and their attributes pertaining to an IPv6. 6.1 Label Label is the 20-bit, fixed length Flow Label identifier in the IPv6 header that a node in the 6LSA binds to a Forwarding Equivalency Class (FEC) and uses it to forward the packet. The label thus represents 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 nodes. 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 Forwarding Equivalence Class (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 the source node desires special handling by the intervening nodes. 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 3-tuple of source address, destination address and label value in the Flow Label in 6LSA. All packets Chakravorty Expires August 21, 2005 [Page 10] Internet-Draft IPv6 Label Switching Architecture February 2005 belonging to the same flow must be sent with the same Flow Label. There may be multiple active flows in the 6LSA at any given time. Further applicable statements are quoted here from [3] RFC 2460 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. If any of those packets includes a Hop-by-Hop Options header, then they all must be originated with the same Hop-by-Hop Options header contents (excluding the Next Header field of the Hop-by-Hop Options header). If any of those packets includes a Routing header, then they all must be originated with the same contents in all extension headers up to and including the Routing header (excluding the Next Header field in the Routing header). The routers 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 Pseudoflow This specification introduces the concept of pseudoflow. A pseudoflow is specified by the Flow Label only. Unlike the 3-tuple definition of the flow [1], a pseudoflow is defined by the one-tuple Flow Label. In a pseudoflow, packets may carry source address of a node other than where the pseudoflow originated and destination address of a node other than where the pseudoflow will terminate. Thus, a pseudoflow originating at an upstream node, which may not be the source node, continues to the next-hop node and terminates in the next-hop node, which may not be the destination node. The label Chakravorty Expires August 21, 2005 [Page 11] Internet-Draft IPv6 Label Switching Architecture February 2005 binding in the lead packet may be reused for a pseudoflow going via nodes downstream of the pseudoflow origination node. This defintion of pseudoflow has been adopted in this specification to avoid confusion with the existing flow defintion in [1]. In 6LSA, if a Flow Label has a 0 (zero) label, the packet containing such a label may still be treated as a part of a group of packets in a "flow" in which all packets have the same source and destination addresses and the same label binding to FEC. The 6LSA node may bind the label to an FEC and process the packet such that it can later be associated with other packets with the same source and destination addresses and FEC binding. The transmission of such packets is called a pseudoflow to distinguish it from the conventional version of flow that comprises a non-zero label. In this document, for simplicity, a pseudoflow is often called a flow when the context is clearly stated. 6.4 Forwarding Equivalence Class (FEC) The Forwarding Equivalence Class (FEC) represents forwarding treatment that a group of IPv6 packets receive. 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.5 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 zero or non-zero Flow Label. All packets in a flow in 6LSA have a non-zero label value, while all packets in a pseudoflow may have zero label value. If an incoming packet into a 6LSA node has a zero label value and it is not a lead packet (see Section 6.7), it may be assigned a non-zero label value before it is forwarded to a downstream node. The label is a part of the IPv6 header and not an extraneous, encapsulating label loaded on the packet. However, the value of the label may be transferred from a packet Flow Label field to a label field in layer 2 such as into an MPLS label space, if adequate label space is available and as the packet moves from a 6LSA domain to an Chakravorty Expires August 21, 2005 [Page 12] Internet-Draft IPv6 Label Switching Architecture February 2005 MPLS-enabled network domain or vice versa. In the case of ATM, the label value may be encoded in the VPI/VCI fields to extend the label and related FEC attributes to the ATM layer. The label from a flow in the 6LSA thus 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 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.6 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 any 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 the former into a next-hop node or 6LSR, or into the latter from a next-hop node or 6LSR. 6.7 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 a 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 packet has no existing entry in the switching table of the 6LSR. All lead packets have a 0 (zero) label coming into the 6LSA nodes from a best-effort network. When source nodes are 6LSA nodes, lead packets may carry non-zero labels. Chakravorty Expires August 21, 2005 [Page 13] Internet-Draft IPv6 Label Switching Architecture February 2005 6.8 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 Section 6.9). 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 is 1 (one), if the packet is a NTL or subsequent packet, that is, it is not a lead packet. 6.9 Switching Table A switching table in 6SLA, similar to what is called the forwarding table in the common networking literature, 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 * PacketÆs next hop * 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. Chakravorty Expires August 21, 2005 [Page 14] Internet-Draft IPv6 Label Switching Architecture February 2005 * The data link layer and encapsulation to use * How the label value needs to be encoded in the Flow 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. 6.10 Attributes of Label Binding The binding of a label to an FEC is based on known attributes of the packet or on externally applied constraints. The FEC may be associated with 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 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 apriori. 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 a related FEC. The binding of a label to 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. 6.11 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 end-to-end, multiple-hop significance within the 6LSA. A 6LSP is thus identified with a sequence of 6LSAs, (R1,i,Rn), 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; Chakravorty Expires August 21, 2005 [Page 15] Internet-Draft IPv6 Label Switching Architecture February 2005 * For all values of i, where 1 < i < n+1, 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 PÆs transit through the network of 6LSRs within a 6LSP, the label value is not bound to a FEC, however, an FEC can be a best-effort delivery FEC; * For all i, where 1 < i < n or 1 < i < 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); * For all i, 1 < i < n, 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 0n 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, more accurately, the sequence of node 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, it also represents the FEC binding of each flow from each of the 6LSR on the 6LSP. In this regard, 6LSP 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 west to east. 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 Chakravorty Expires August 21, 2005 [Page 16] Internet-Draft IPv6 Label Switching Architecture February 2005 be many ingress, intermediate and egress 6LSRs in a 6LSA |L | +-+-+ | | +------------------+ D +---------------+ Non-6LSA | | | | | 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 are merged and sent out on one 6LSP represented by L6. In this case, the flows maintain their identity by their source and destination addresses 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 Expires August 21, 2005 [Page 17] Internet-Draft IPv6 Label Switching Architecture February 2005 +--------------------------------------+ 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. 7. 6LSA Functionalities This section provides details of 6LSA functionalities including label acquiring, label binding to FEC, and label swapping. 7.1 Label Assignment In the 6LSA, the decision to assign or bind a label to a particular FEC is made by a 6LSA node, generally the ingress 6LSR if it is the origination point for that flow; in this case the flow is a pseudoflow by definition. 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. The 6LSA incorporates three models for acquiring label space. The first model specifies locally generated labels; the second model refers to label distribution, and the third, acquires labels from the Chakravorty Expires August 21, 2005 [Page 18] Internet-Draft IPv6 Label Switching Architecture February 2005 Flow Labels available in the 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 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 the 6LSA prevent a node from using any label that was used earlier or gotten from a flow that used an algorithm or a model other than those specified here. The three models for label generation in this document are detailed below. 7.1.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 in which the bit fields are within the parameters specified in Section 6.1, Label. It is envisioned that a set of labels will be genrated 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 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 any network management or other systems. Methodologies for such refreshment are outside the scope of this specification. The 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 Chakravorty Expires August 21, 2005 [Page 19] Internet-Draft IPv6 Label Switching Architecture February 2005 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 (see Section 7.1.2 below). 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. 7.1.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 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. How label binding is distributed when applicable in the 6LSA and how a node binds a label to a FEC are outside the scope of this document. The flows generated by the 6LSA nodes using this model do not meet the definition of flow as specified in [2] and [3]. 7.1.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. This label model is not recommended for large 6LSA domains; in large domains undesirable duplication of labels can occur. This model requires a single-bit field, the MSB field, in the label to represent the identity of the packet as the lead packet or non-lead packet. It is similar to the PID value in the switching table. In the model, if this PID-representative bit is 0 (zero), the packet is a lead packet and if it is 1 (one), the packet is not a lead packet but a NTL or subsequent packet. This bit assignment requires IANA registration which has not been done for this specification. This bit assignment potentially reduces the number of 6LSPs between two peering nodes to one half of a million from a million. Details of this model remain to be developed for future specification. Chakravorty Expires August 21, 2005 [Page 20] Internet-Draft IPv6 Label Switching Architecture February 2005 7.2 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. A pseudoflow, on the other hand, originates at an upstream 6LSA node, which may be a 6LSR, continues to the next-hop node and terminates there. This next-hop node may also be a 6LSR. The lead packet in a pseudoflow carries a 0 (zero) label. For the example shown in Figure 3, an upstream 6LSA node, A, may bind a label L1 to FEC X for a flow to a downstream node, B, and B may use the same label, L1, or a different label (not shown) to identify a return flow Y from B to A, while at the same time A may bind another label L2 to FEC X for a different flow to node, C, which in turn may bind label L1 to FEC X for a flow to node D and label L2 to FEC X to another node E. | | +-+-+ +---+ L1 | |L1/X --> | | --------------------------+ A +-----------------+ B |---- | |<-- L1/Y | | +-+-+ +---+ | |L2/X | | +---+ +-+-+ +---+ L4 | | L1/X | |L2/X | | -------+ D +-----------------+ C +-----------------+ E +---- | | | | | | +---+ +-+-+ +---+ Unique Labels for Unique Flows Figure 3. Chakravorty Expires August 21, 2005 [Page 21] Internet-Draft IPv6 Label Switching Architecture February 2005 Conversely, a given upstream node, A, may bind label L to FEC F1 and then to FEC F2 so long as these FECs represent flows to different downstream nodes, in this case, B and C. See Figure 4 below. | | +-+-+ +---+ L | |L/F1 | | --------------------------+ A +-----------------+ B +---- | | | | +-+-+ +---+ |L/F2 | | | | | +---+ +-+-+ +---+ L | | L/F2 | |L/F2 | | -------+ D +-----------------+ C +-----------------+ E +---- | | | | | | +---+ +-+-+ +---+ Same Label in Multiple Flows Figure 4. However, two upstream nodes, A and C, may bind label L to FEC F1 and also to FEC F2 for two different flows to the same downstream node, B, provided B is able to determine that the two flows are different otherwise the 6LSA requires that the upstream 6LSR not bind the same label to two different flows to the same next-hop 6LSR. See Figure 5 below, in this case the downstream 6LSR is able to determine that the two flows are different. What applies to two flows also applies to more than two flows. Multiple flows from upstream 6LSRs may bind label L to multiple FECs F1, F2, F3, etc., for multiple flows as shown in Figure 6, or to the same FEC F for multiple flows. The 6LSR B binds one label to all the outgoing flows to the downstream 6LSR C. This is called flow merging. In this case, C is not able to determine on its own that multiple flows from B are different because they carry the same label and arrive on the same interface. The differentiation is possible if the downstream 6LSR can identify the uniqueness of the flows through source and destination addresses, if an extraneous label distribution protocol such as the Distributed Label Model is used, or if the 6LSA Chakravorty Expires August 21, 2005 [Page 22] Internet-Draft IPv6 Label Switching Architecture February 2005 locally distributed label model carries a specific lead packet identifier bit, such as the PID-representative bit as in the Reuse Label model. +---+ +---+ | | | | ------+ A | | C +------ ____ | | | | +-+-+ +-+-+ | | | | L/F2 | +---------+ | | | +-+-+ | L/F1 | | +--------------------+ B +---- | | +-+-+ Same Label for Multiple Flows into Different Interfaces Figure 5. | | |L/F4 +---+ +-+-+ +---+ | | L/F1, F2, F3--> | | | | -----+ +-----------------+ |L/F5--> | +---- -----+ A +-----------------+ B +-----------------+ C +---- -----+ +-----------------+ | | +---- | | | | | |_ +---+ +-+-+ +---+ Merging Flows Figure 6. 7.3 Label Retention Mode If a 6LSR B receives a label binding from a 6LSR A for a particular FEC via an 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 Chakravorty Expires August 21, 2005 [Page 23] Internet-Draft IPv6 Label Switching Architecture February 2005 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 6.5. 7.4 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 nature of the forwarding treatment and how it is applied is out of scope for this document. The only exception to this rule may be a case when a label value is assigned globally, by policy, for example. 7.5 Label Stacking The 6LSA does not allow label stacking. There is only one label in a 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. 7.6 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 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. 7.7 Packet Processing Algorithm The 6LSA packet processing algorithm includes handling packets that arrive from the outside networks into the 6LSA domain or when they arrive from hosts in the same 6LSA domain. The 6LSA domain processing provides QoS priority handling or such other treatment that the packets need. In this section, the sequence of basic steps needed for processing a packet inside 6LSA is detailed. Chakravorty Expires August 21, 2005 [Page 24] Internet-Draft IPv6 Label Switching Architecture February 2005 The simplest 6LSA domain consists of three nodes: the source node or ingress 6LSR, one destination node or egress 6LSR, and one 6LSR in between, the intermediate 6LSR. In the next, more complex network configuration, there are four or more nodes with two or more intermediate 6LSRs. 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 and the flow arrives on the same interface. Since there is no label stacking in 6LSA, there is no inherent advantage in flow merging. Packets from different flows when merged into a single flow will still have different source and destination addresses, and distinction between flows thus can be made by the source and destination addresses when the merged flow arrives at a downstream node. If the incoming flows arrive on different 6LSPs and thus on different interfaces, then flows can be distinguished by their labels and/or by incoming interfaces. As the complexity grows, there may be a combination of incoming flows representing different LSPs: merged and non-merged. In each step of packet processing, there are activities that relate to the components of the IPv6 header in addition to the Flow Label. One such component is the Hop Limit that is incremented every time a packet passes through a node in the 6LSA. Additionally, if the packet has header extensions, such as Hop-by-Hop or Routing Header, they are processed as in the conventional IPv6 routing environment. Such extensions may be represented in the FEC. Recall that a 6LSA node must use only one label model at any time, for example, if it is using the Distributed Label Model, it must not use the Locally Generated Label Model. 7.7.1 Packet Processing in Locally Generated Label Model The key considerations of packet processing in this model are as follows: * A 6LSA domain network peers in Layer 3 with one or more other networking domains. * All packets into and out of 6LSA domains carry 0 (zero) labels. * Within a 6LSA domain, a source node may generate one or more unique labels and forward all packets with one, unique label for a given flow, or may forward lead packet with a 0 (zero) label and the NTL and subsequent packets with locally generated label. Chakravorty Expires August 21, 2005 [Page 25] Internet-Draft IPv6 Label Switching Architecture February 2005 * If the lead packet from an upstream node is lost before reaching the next-hop 6LSR, then the NTL packet with a non-zero label will be treated by the downstream 6LSR as the lead packet and forwarded with the same incoming non-zero label. * If a lead packet with a 0 (zero) label in a flow is forwarded to a next-hop 6LSR different from the one to which the NTL and subsequent packets from the same flow (such all packets having the same source and destination addresses) are forwarded to, then two scenarios are possible. If the lead packet shows up before the NTL packet in the downstream 6LSR, then the forwarding process will be as specified here. However, if the lead packet shows up after the NTL or subsequent packet, then the lead packet is processed as a lead packet while the NTL packet is also processed as a lead packet but with its non-zero label. Based on the flow characteristics and label bindings, the 6LSR however may provide the same forwarding treatment to both flows and thus forward the packets out the same interface over the same 6LSP. If this is an egress 6LSR, the outgoing label will be zero in all the packets. * If a lead packet with a non-zero label in a flow is forwarded to a next-hop 6LSR different from the one to which the NTL and subsequent packets from the same flow (such all packets having the same source and destination addresses) are forwarded to, then two scenarios are possible here as well. If the lead packet shows up before the NTL packet in the downstream 6LSR, then the forwarding process will be as specified here. However, if the lead packet shows up after the NTL or subsequent packet, then the lead packet is processed as an NTL or subsequent packet while the NTL packet is processed as a lead packet all with the same non-zero label. Based on the flow characteristics and label bindings, the 6LSR however may provide the same forwarding treatment to both the incoming flows and thus forward the packets out the same interface over the same 6LSP. If this is an egress 6LSR, the outgoing label will be zero in all the packets. * If there is a match for the incoming label and interface in the switching table, then the incoming label is swapped with the outgoing label from the switching table. The PID value in the switching table is updated to 1 (one) if it was 0 (zero). * In egress 6LSR peering with some other network router, FEC does not exist since the packets are transmitted out to the other network based on the next-hop address. * If packets carrying non-zero labels arrives from an external, non-6LSA domain into the 6LSA domain, either erroneously or maliciously, the 6LSA domain does not guarantee the forwarding of Chakravorty Expires August 21, 2005 [Page 26] Internet-Draft IPv6 Label Switching Architecture February 2005 such packets with the incoming label via its domain out to the same or other external domain unless the label binding is available apriori to the egress 6LSR. If this is not the case, the 6LSA domain may forward the packet with a zero-label from the egress 6LSR. This may by default enhance security of the overall end-to-end networking. In the following paragraphs, the packet processing in three different types of 6LSA nodes is detailed for non-merging and merging flows. 7.7.1.1 Packet Processing Example For an understanding of the process of label switching, a relatively +-----------------------------------------------------+ | | | | | Ingress Intermdt. Egress | | 6LSR 6LSR 6LSR | | +-------+ +-------+ +-------+ | | | | | | | | | ---|--+ +----------+ +----------+ +----|--- | | A | | C | | B | | ---|--+ +----------+ +----------+ +----|--- | | | | | | | | | +-------+ +-------+ +-------+ | | | | | | | +-----------------------------------------------------+ Packet Processing Figure 7. simple configuration is used, see Figure 7 in which pseudoflows, called flows in this description for simplicity, originate in each of the upstream node and terminate in the next-hop, downstream node. Representative packet flows and switching table entries are given in the table in Figure 8. In the table, for each packet in each switching table entry column, 0 (zero) and Ln are the label values in the top row, Sn and Dn are the source and destination addresses in the bottom row, and 0 (zero) and 1 (one) are the PID values in the middle row. Chakravorty Expires August 21, 2005 [Page 27] Internet-Draft IPv6 Label Switching Architecture February 2005 ---------------------------------------------------------------------- | | | | | | Incoming |Swtchg.|Transiting|Swtchg.|Transiting|Swtchg.| Outgoing Packet | Table | Packet | Table | Packet | Table | Packet | Entry | | Entry | | Entry | ---------------------------------------------------------------------- First Flow ---------> | | | | | | 0 |0 L1| 0 |0 L2| 0 |0 0| 0 Lead Pkt --> | 0 |--------->| 0 |--------->| 0 |----> S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 |S1,D1 | | | | | | | | | | | | 0 |0 L1| L1 |L1 L2| L2 |L2 0| 0 NTL Pkt ---> | 0-1 |--------->| 0-1 |--------->| 0-1 |----> S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 |S1,D1 | | | | | | | | | | | | 0 |0 L1| L1 |L1 L2| L2 |L2 0| 0 Sub. Pkt---> | 1 |--------->| 1 |--------->| 1 |----> S1,D1 | S1,D1 | S1,D1 | | S1,D1 | S1,D1 |S1,D1 | | | | | | All other packets in this flow have the same characteristics as the Subsequent Packet. ---------------------------------------------------------------------- Second Flow ---------> | | | | | | 0 |0 L3| 0 |0 L4| 0 |0 0| 0 Lead Pkt --->| 0 |--------->| 0 |--------->| 0 |-----> S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | | | | | | | | | | | | 0 |0 L3| L3 |L3 L4| L4 |L4 0| 0 NTL Pkt ---> | 0-1 |--------->| 0-1 |--------->| 0-1 |-----> S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | | | | | | | | | | | | 0 |0 L1| L3 |L3 L4| L4 |L4 0| 0 Sub. Pkt--->| 1 |--------->| 1 |--------->| 1 |-----> S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | | | | | | Chakravorty Expires August 21, 2005 [Page 28] Internet-Draft IPv6 Label Switching Architecture February 2005 All other packets in this flow have the same characteristics as the Subsequent Packet and the following flows are similar to the second flow. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Label Swapping Operation for Non-Merging Flows Figure 8. The values in the incoming, transiting and outgoing packet columns below indicate incoming label, and source and destination address values. All packets are arriving into A from a non-6LSA, best effort domain and going out of C into a non-6LSA and therefore all packets have 0 (zero) label. The following observations represent the packet processing in Figure 8. The label in the lead packet of a flow is not swapped in any of the 6LSRs regardless of its label. The PID value in the switching table is 0 (zero) for the lead packet. The 6LSR acquires a label, binds the lead packet label to a FEC and makes an entry in the 6LSR switching table for the incoming label as well as the acquired label for this flow, incoming interface (the physical port or link on which the packet arrived is not shown), outgoing interface (not shown), source and destination addresses, and the FEC (not shown). The outgoing interface, that is, the physical port or link on which the packet has to be transmitted out is determined from the IPv6 routing table, FEC or other similar means, and entered into the switching table. How the 6LSR determines the best interface for the given FEC is outside the scope of this document and will be specified in future work. The label in each NTL packet, as well as the label in each packet thereafter is swapped with an outgoing label, meaning, the incoming label is replaced with a unique, acquired label. This label is the same in all outgoing packets for the same flow irrespective of whether the outgoing label is acquired through Locally Generated Label Model or through some other means. The label entry may be flagged for the way the label was acquired by the 6LSR, however, such flagging is outside the scope of this specification. After the label is swapped, the 6LSR binds the label to the FEC and applies the forwarding treatment for that FEC. The labeled packet is forwarded out of the interface that is determined by the applicable routing protocol. Chakravorty Expires August 21, 2005 [Page 29] Internet-Draft IPv6 Label Switching Architecture February 2005 7.7.1.2 Algorithm for Non-Merging Flows The following steps describe the operations of this algorithm. The algorithm changes for the 6LSA in which all nodes, that is, the source and destination nodes as well as all 6LSRs, exist in the 6LSA domain. In this case, lead packets from the source node may carry non-zero labels. When such packets arrive at the first 6LSR, the latter can determine they are lead packets, and maintains the label. So does all other intermediate 6LSRs. The last 6LSR, possibly one hop upstream of the destination node, maintains this label also since the next node, the destination node is in the 6LSA domain. a) Ingress 6LSR: when a packet arrives on an interface, match source and destination addresses in the incoming packet with those in the switching table. i) If there is no match, this is a lead packet; acquire an outgoing label which is unique for the outgoing interface and represents the pre-selected FEC for this flow, make switching table entry for this packet including the labels and the PID value of 0 (zero), and forward the packet out; there is no swapping of incoming with the outgoing label. ii) If there is a match, and the PID value is 0 (zero) in the switching table, this is an NTL packet in the flow. Swap the incoming label with the outgoing one in the switching table, set the PID to 1 (one), and forward the packet out. iii)If there is a match and the PID value is 1 (one) in the switching table, this is a subsequent packet in the flow. Swap the incoming label with the outgoing label and forward the packet. b) Intermediate 6LSR: when a packet arrives on an interface, match the incoming label and interface with those in the switching table. i) If there is no match, this is a lead packet and the operation is same as a(i) above. ii) If there is a match for only the incoming label, i.e., if no outgoing label exists, then this is a lead packet and the operation is same as a(i) above. iii) If there is a match, for both the label and the interface, this is an NTL or a subsequent packet in this flow. Swap the incoming label with the outgoing label and forward the packet out. Chakravorty Expires August 21, 2005 [Page 30] Internet-Draft IPv6 Label Switching Architecture February 2005 c) Egress 6LSR: when a packet arrives on an interface, match the incoming label and interface with those in the switching table. i) If there is no match, this is a lead packet, look up the next-hop route and make switching table entry for this packet including the label, the PID value of 0 (zero) and the route for the outgoing packet, and forward the packet out; there is no label binding, and there is no label swapping if the incoming label is 0 (zero) otherwise swap the incoming label with 0 (zero) label for peering with the best-effort network. ii) If there is a match for only the incoming label and not the interface, then this is a lead packet and the operation is same as c(i) here above. iii) If there is a match for both the label and interface in the same entry, this is an NTL or a subsequent packet in this flow and the operation is same b(iii) above. 7.7.1.3 Algorithm for Merging Flows Packets arriving at a downstream 6LSA node that belong to different flows but have the same label and arrive on the same interface are said to belong to a merged flow. Such packets cannot be efficiently differentiated by the downstream node without the apriori knowledge of how the flows were merged in the upstream 6LSR or through some other means. The following steps describe the operations of the algorithm when the flows out of the upstream 6LSR are merged and forwarded as a single flow to the next-hop 6SLR. a) Ingress 6LSR: when a packet arrives on an interface, match source and destination addresses in the incoming packet with that in the switching table. The matching by source and destination addresses identifies the uniqueness of the flow. i) If there is no match, this is a lead packet and the operation is same as for the lead packet described above in a(i). ii) If there is a match, and the PID value is 0 (zero) in the switching table, this is an NTL packet in the flow, swap the incoming label with the outgoing one in the switching table, increment the PID to 1 (one), and forward the packet out. Chakravorty Expires August 21, 2005 [Page 31] Internet-Draft IPv6 Label Switching Architecture February 2005 iii) If there is a match and the PID value is 1 (one) in the switching table, this a subsequent packet in the flow, switch the incoming label with the outgoing label and forward the packet out. b) Intermediate 6LSR: when a packet arrives on an interface, match the incoming label and interface with those in the switching table. i) If there is no match, this is a lead packet and the operation is same as a(i) above. ii) If there is a match for the incoming label and not the incoming interface, and the PID value is 0 (zero) in the switching table, then this is a lead packet and the operation is same as b(i) here. iii)If there is a match for both the label and the interface in the same entry, this is an NTL or a subsequent packet in this flow or another flow (if the upstream 6LSA node is merging flows), find a match for the source and destination addresses - - If there is a match, this is an NTL or a subsequent packet, the operation is same as for an NTL or subsequent packet describe above. - If there is no match, this is a lead packet and the operations are the same as described before for the lead packet. c) In the egress 6LSR, when a packet arrives on an interface, match the incoming label and interface with those in the switching table. i) If there is no match, this is a lead packet, the operation is same as for a lead packet in an egress router as described above. ii) If there is a match for only the incoming label and not the interface, and the PID value is 0 (zero) in the switching table, then this is a lead packet and the operation is same as above for a lead packet exiting an egree 6LSR. iii) If there is a match for both the label and the interface in the same entry, then this is an NTL or a subsequent packet in this flow or another flow (if the upstream 6LSR is merging flows). Find matches for the source and destination addresses. - If there is a match of the addresses, this is a next-to-lead or subsequent packet; increment the PID to 1 (one) and forward the packet out after swapping incoming label with a 0 (zero) label. Chakravorty Expires August 21, 2005 [Page 32] Internet-Draft IPv6 Label Switching Architecture February 2005 - If there is no match, this is a lead packet and the operations are the same as described before for a lead packet. 7.7.2 Packet Processing in Reuse Label Model Packet processing in this model is similar to that in the above packet processing description for the Locally Generated Label Model. The main difference is that in the label, the PID-representative bit is 0 (zero) when the packet is processed as a lead packet and 1 (one), when the packet is processed not as a lead packet. Details will be provided in future version of this specification. 7.7.3 Packet Processing in the Distributed Label Model Packet processing in this model is out of scope of this specification. This is for future work and specification. 7.8 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. 7.9 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. 7.10 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. 7.11 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 Chakravorty Expires August 21, 2005 [Page 33] Internet-Draft IPv6 Label Switching Architecture February 2005 be discarded after the lead packet is forwarded in a pseudoflow. Invalid labels may not include a zero-labeled packet. The discussion of the values of such labels are outside the scope of this specification. 7.11.1 LSP Control: Ordered and Loose As described in the MPLS label switching architecture [2], 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. This is for further work and documentation. 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. 7.12 Aggregation 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 aggregation may further be decided by the IPv6 packet header Traffic Class parameters. 7.13 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 7.7 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. Chakravorty Expires August 21, 2005 [Page 34] Internet-Draft IPv6 Label Switching Architecture February 2005 7.13.1 Hop-by-Hop Routing using Hop-by-Hop Header Extension To ensure per hop 6LSP execution, the 6LSA allows use of Hop-by-Hop Options header, identified by a Next Header value of 0 (zero) in the IPv6 header. This increases processing at each node since the packet carries optional information that needs processing by every 6LSR along a packet's route. 7.13.2 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. 7.14 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. 7.15 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 layer 2 label encoding. How a 6LSA label value is encoded in the ATM VPI/VCI field is outside the scope of this document. 7.16 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 Chakravorty Expires August 21, 2005 [Page 35] Internet-Draft IPv6 Label Switching Architecture February 2005 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. 7.17 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. 8. Security Considerations The 6SLA allows security association. If the security association (SA) 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. 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 Chakravorty Expires August 21, 2005 [Page 36] Internet-Draft IPv6 Label Switching Architecture February 2005 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. 9. Informative Referneces [1] J. Rahjahalme, et al, IPv6 Flow Label Specification, RFC 3697, March 2004. [2] Rosen, E. Viswanathan, A. and Callon, R., Ÿ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 Deering, S., IPv6 Multicast Address Assignments, RFC 2375, July 1998. Awduche, D., et al, ŸRequirements for Traffic Engineering Over MPLSË, RFC 2702, September 1999. [5] Awduche, D., et al, Overview and Principles of Internet Traffic Engineering, RFC 3272, May 2002. [6] Agarwal, P. and Akyol B., Time to Live (TTL) Processing in MPLS Networks, RFC 3443, January 2003. [7] Hinden, R. and Deering, S., IPv6 Addressing Architecture, RFC 3513, April 2003. 10. Acknowlegements The author deeply appreciates significant editing contributions made by Keith Scott (MITRE), implementation support provided by Don Chirieleison (MITRE) and valuable general advice and encouragement received from Jim Bound (HP). The author also gratefully Chakravorty Expires August 21, 2005 [Page 37] Internet-Draft IPv6 Label Switching Architecture February 2005 acknowledges overall management support for implementation of this protocol received from Jim Providakes (MITRE). 11. Disclaimer The authorÆs affiliation 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 author. 12. Implementation Direction A LINUX implementation of basic 6lsa operation has been completed. This may be made available to interested parties. Future plans include enhancments to the implementation and modeling and simulation of 6lsa to test its scalability and performance. Author's Address Sham Chakravorty The MITRE Corporation 1575 Colshire Dr. McLean, VA 22102 USA EMail: schakra@mitre.org Chakravorty Expires August 21, 2005 [Page 38] Internet-Draft IPv6 Label Switching Architecture February 2005 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 (2005). 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 Expires August 21, 2005 [Page 39]