Internet Draft S. Chakravorty Document: draft-chakravorty-6lsa-00.txt Mitre Corp. Expires: 5 December 2004 6 July 2004 IPv6 Label Switching Architecture (6LSA) draft-chakravorty-6lsa-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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 document provides specifications for IPv6 label switching architecture (6LSA) and associated IPv6 packet transport mechanisms. Abstract This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet switching technique that uses the IPv6 packet header Flow Label, header extensions, and unique routing algorithms, the latter two when needed, 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) solutions as in IPv4-based MPLS or ATM. Since MPLS-like protocol labeling will be redundant for IPv6 and since there are no widely-known QoS deployments of IPv6 over any of the layer 2 switching mechanisms such as ATM, the 6LSA framework fills the technology void without the link overhead from extraneous layer 2 labeling and signaling of MPLS, or packet fragmentation and added signaling as in ATM. Through the use of fast switching of 20-bit labels instead of 128-bit IPv6 address look-ups, the architecture presented here also provides processing savings through significantly reduced address fetches for the low-powered, handheld devices. Table of Contents 1. Introduction.....................................................2 2. Overview.........................................................3 3. Terminology......................................................4 4. Distinguishing Characteristics of 6LSA...........................6 5. Routing Versus Switching of IP Traffic...........................7 6. 6LSA Basic Components and Their Attributes.......................8 6.1 Label.......................................................8 Chakravorty Expires - December 2004 [Page 1]
draft-chakravorty-6lsa-00.txt August 2004 6.2 Flow........................................................8 6.3 Pseudoflow..................................................9 6.4 Forwarding Equivalence Class (FEC).........................10 6.5 Labeled Packet.............................................10 6.6 IPv6 Label Switching Router (6LSR).........................10 6.7 Lead Packet................................................11 6.8 Packet Identifier (PID) Field..............................11 6.9 Switching Table............................................11 6.10 Attributes of Label Binding...............................11 6.11 IPv6 Label Switched Path (6LSP)...........................12 7. 6LSA Functionalities............................................14 7.1 Label Assignment...........................................14 7.2 Scope and Uniqueness of Labels.............................16 7.3 Label Retention Mode.......................................18 7.4 Packet Forwarding..........................................18 7.5 Label Stacking.............................................18 7.6 Label Swapping.............................................18 7.7 Packet Processing Algorithm................................18 7.8 Fast Switching.............................................25 7.9 FEC Mapping................................................25 7.10 Penultimate 6LSR Label Processing.........................25 7.11 Invalid Incoming Labels...................................25 7.12 Aggregation...............................................26 7.13 Route Selection...........................................26 7.14 Control...................................................26 7.15 Label Encodings...........................................26 7.16 Anycast in 6LSA...........................................26 7.17 Multicast in 6LSA.........................................27 8. Security Considerations.........................................27 9. Informative References..........................................27 10. Acknowledgements...............................................28 11. AuthorÆs Addresses.............................................28 12.................................................................28 1. Introduction Several approaches have been developed over the past decade to provide packet switching and QoS to IPv4 flows. These include MPLS, ATM, extensions to routing protocols such as IGP, IS-IS and OSPF, and proprietary. Some of these techniques can also be applied to IPv6 transport but not directly. An MPLS mechanism for IPv6 would amount to redundant labeling; what is commonly proposed is IPv6 to IPv4 translation or tunneling and then using MPLS. There is no widely known deployment where one or more of the common layer 2 switching techniques have been used with IPv6 for QoS delivery. However, IPv6 offers strong features to enable switching of IPv6 packets, most significant among them are the provision of the Flow Label and the Routing Header extension. This framework thus fills the void that absence of such IPv6 switching technologies present. The IPv6 Label Switching Architecture (6LSA) eliminates the link overhead from extraneous layer 2 labeling and signaling as in MPLS, or packet fragmentation and added signaling as in ATM. The fast switching of 20-bit labels instead of 128-bit IPv6 address look-ups also provides processing savings 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 label switched paths of local significance to provide QoS for connection-oriented flows that cannot be provided by a purely routed, connectionless approach. The 6LSA allows local label generation that can Chakravorty Expires - December 2004 [Page 2]
draft-chakravorty-6lsa-00.txt August 2004 help update label values in a synchronized manner across the network to reduce man-in-the-middle attacks. In essence, the 6LSA provides the means for static and mobile nodes to set up label switched paths, automatically and/or manually, to provide secure end-to-end QoS. 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 IPv6 Flow Label switched paths, also called IPv6 label switched paths (6LSPs). The specification of IPv6 label is in conformance with [2] RFC 3697, IPv6 Flow Label Specification, in which the use of Flow Label has been recommended for establishing different types of flows end-to- end. Indeed, the proposed mechanism of IPv6 label switching significantly broadens the scope of the use of Flow Labels beyond its mere use for flow identification. 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 for the same destination was processed and forwarded, the routing is considered connectionless. As noted in [1] ¡ RFC 3031, 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 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. The assignment of packets to an FEC is called binding. 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 thus either available in the incoming packetÆs Flow Label, locally generated based on certain algorithm or policy, or distributed through a label distribution process. 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. As in the MPLS Architecture [1], a packet is labeled before it is forwarded, however, unlike MPLS, the label may be strictly local-node based 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 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 go through the same process of label selection and assignment. Packet forwarding is done using the 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, also called a switching 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 switching table is checked using the Chakravorty Expires - December 2004 [Page 3]
draft-chakravorty-6lsa-00.txt August 2004 algorithms described here to see if there is a label for the flow. If none exists, a label is assigned to the packet and the packet is treated as a lead packet. If a label value exists in the switching 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 the switching 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 which itself is based on one or more packet characteristics. What characteristics should be chosen for what FEC is an administrative, QoS, or policy decision, or a combination thereof. Such a decision is meant to support certain traffic engineering 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 the 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 [1] and are applied to the 6LSA specification as appropriate for consistency. FEC Forwarding Equivalent Class; the forwarding treatment that a collection of IP packets receives; such packets all have the same characteristics from a QoS perspective, receive the same forwarding treatment, and are generally forwarded over the same label switched path (6LSP) label the IPv6 Flow Label which is carried in the IPv6 packet header and used in 6LSA, and which may represent the packet's FEC flow a flow is a sequence of packets identified by the 3- tuple of source and destination addresses, and the Flow Label Flow Label the 20-bit label in the IPv6 header used for identifying flows flow merge same as label merging, when it is applied to flows label merging the replacement of multiple incoming labels with a single outgoing label label swapping the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, port, and other data handling information and then replacing the incoming label with the outgoing label which may or may not be the same as the incoming label Chakravorty Expires - December 2004 [Page 4]
draft-chakravorty-6lsa-00.txt August 2004 label switching a fast forwarding operation allowing streamlined forwarding of packets by using labels to identify classes of data packets which are treated indistinguishably when forwarding label switched hop the hop between two 6LSA nodes, on which forwarding is done using labels label switched path a virtual path through which all packets in a flow are routed across a routing or administrative domain lead packet a packet arriving at a 6LSA node that is the first packet in the flow that this node has received and carries a 0 (zero) label if arriving from a non- 6LSA domain and may carry a non-zero label if arriving from an upstream 6LSA node next-to-the- lead packet a packet that arrives at a 6LSA node after the lead packet of the flow, also called an NTL packet node may be a source or intermediate node in the 6LSA domain or non-6LSA domain unless identified specifically as a source node pseudoflow a flow that has the lead packet carrying a 0 (zero) label, or packets carrying source address of a node other than where the flow originated and destination address of a node other than where the flow will terminate 6LSA domain a contiguous set of nodes that perform 6LSA routing and forwarding operations and are in one routing or administrative domain 6LSA egress node a 6LSA edge node in its role of handling traffic as the traffic leaves a 6LSA domain 6LSA ingress node a 6LSA edge node in its role of handling traffic as the traffic enters a 6LSA domain 6LSP a label switched path through a pair or more 6LSRs 6LSR IPv6 label switching router that is capable of forwarding IPv6 packets based on certain pre- selected FEC attributes source node a 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 switched path synonymous with label switched path virtual circuit (VC) a circuit used by a connection-oriented layer 2 technologies such as ATM or Frame Relay, requiring the maintenance of state information in layer 2 switches VC merge label merging where the 6LSA label is carried in the ATM VCI field (or in the combined VPI/VCI field), so as to allow multiple VCs to merge into one single VC Chakravorty Expires - December 2004 [Page 5]
draft-chakravorty-6lsa-00.txt August 2004 VP merge label merging where the 6LSA label is carried in the ATM VPI field, so as to allow multiple VPs to be merged into one single VP; in this case two cells would have the same VCI value only if they originated from the same node; this allows cells from different sources to be distinguished via the VCI 4. Distinguishing Characteristics of 6LSA The 6LSA characteristics justify its application wherever IPv6 is deployed and where QoS network performance delivery is required or where other available packet switching mechanisms cannot deliver network performance end-to-end. The special characteristics of 6LSA are listed here in no particular order: 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. o No-Extraneous-Label-Binding Option ¡ 6LSA offers the option to avoid the use of any extraneous labels and thus avoid the need for label distribution across the network in the control plane as is done in MPLS. o No Label Distribution Protocols - There is no need for label distribution protocol so as to be able to map labels to addresses across the network(s). o Elimination of Label Distribution Traffic ¡ Absent a control plane for label distribution, there is no control plane traffic. o No Label Distribution State Machine ¡ Without label distribution, there is no need for a separate state machine for the maintenance of extraneous labels. o Free of Layer 2 Overheads - Being a layer 3 packet switching solution, 6LSA does not need a layer 2 packet switching mechanism such as ATM, MPLS or switched Frame Relay and as such 6LSA avoids ATMÆs fragmentation and reassembly of IP packets and thus eliminates the resulting 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, 6LSA tends to avoid the potential for O(N2) and O(N3) problems. o Deployment Ease - The 6LSA can be deployed over simple layer 2 protocols such as Ethernet and PPP. This should help expedite the deployment of IP over DWDM. 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 if needed, conversely, both the fields may be used together in the 6LSA. (This is a subject for further work and documentation.) Neither MPLS or nor ATM provides this capability, indeed MPLS is allowed to forfeit up to 5 bits from its label space for QoS marking. o Feature Visibility to Applications ¡ Unlike ATM or MPLS, all of IPv6Æs packet features are available to upper layer APIs. In the case of ATM, whole IP packets have to be reassembled for common IP APIs to work, while in MPLS, one or more labels have to be removed. Chakravorty Expires - December 2004 [Page 6]
draft-chakravorty-6lsa-00.txt August 2004 o Extensive Operational Flexibility - 6LSA provides the flexibility between switching and routing as needed without the need for label popping or any additional processing for exiting the 6LSA mode of operation and then again reverting back to 6LSA. Thus any two peering nodes can have a best- effort routing between them on a pair of interfaces while on other interfaces, the same two nodes may forward the same packets over 6LSPs. The 6LSA thus allows the best of both worlds for transmission ¡ one with a single class of traffic and the other with multiple classes of traffic. 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. o Hop Limit field - the 8-bit hop limit field in the IPv6 header is available for loop prevention. There is no need to port this value to an extraneous label. o No MTU Violation ¡ since the packet size does not change because of the addition of extraneous labels, 6LSA eliminates the potential for MTU violations. o Fast Switching in IPv6 ¡ the 6LSA protocol provides for a fast label switching mechanism heretofore available only in IPv4 through the use of MPLS. To summarize, 6LSA provides a significantly efficient and powerful layer 3 mechanism for switching IP packets - with little or no added overhead for establishing label switched paths - for end-to-end, granular QoS delivery. 5. Routing Versus Switching of IP Traffic The routing of packets on the Internet has the following essential characteristics. ¡ Routing is connectionless and comprises non-sequential packet transport. ¡ The technique is essentially store-and-forward and involves slow route processing. ¡ The paths are not dedicated (non-switched) virtual paths - for the duration of a session, the inter-router or inter-device paths may vary many times for a given flow. ¡ There are generally no delivery or QoS guarantees - a single class of traffic is available. ¡ The process is geared more toward routing flexibility than speed. ¡ The routing protocols are generally developed by the IETF. Switching of packets has the following basic characteristics. ¡ The ôroutingö of packets is connection-oriented; the flow of packets comprises sequential packets. ¡ The packet processing can be cut-through and therefore extremely fast. Chakravorty Expires - December 2004 [Page 7]
draft-chakravorty-6lsa-00.txt August 2004 ¡ The packets travel over dedicated, virtual paths which are either permanent or temporary. ¡ Switching is generally associated with certain delivery guarantees and traffic classification. ¡ The technique is geared more toward speed than routing flexibility. The issues with switching are: ¡ There are delays caused by VC setup time across the network. ¡ There is the need for VC state maintenance. ¡ IP address to VC translation latency is always present however small. ¡ Hardware performance has not always been up to demand since switching is a rather fast process. ¡ Potential for large resource wastage in case of link or node failure in IP virtual network over switched network, for example IP over ATM that may cause N2 and N3 problems. ¡ Generally there is no error correction enroute. ¡ Most switching protocols are not developed by the IETF. The 6LSA overcomes most of these disadvantages as will be shown below. 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 Labels are 20-bit, fixed length Flow Label identifiers 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 Chakravorty Expires - December 2004 [Page 8]
draft-chakravorty-6lsa-00.txt August 2004 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 comprises source and destination addresses as well as the label value in the Flow Label. All packets belonging to the same flow must be sent with the same source address, destination address and 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. In 6LSA, if a Flow Label has a zero value, 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 packet to a 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 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 binding in the lead packet may be reused for a pseudoflow going via nodes downstream of the pseudoflow origination node. In this document, for simplicity, a pseudoflow is often called a flow when the context is clearly stated. Chakravorty Expires - December 2004 [Page 9]
draft-chakravorty-6lsa-00.txt August 2004 6.4 Forwarding Equivalence Class (FEC) The Forwarding Equivalence Class (FEC) represents forwarding treatment 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 value. 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 is assigned a non- zero label value before forwarding it. This is because in 6LSA, a zero label is used to indicate that the packet is part of a pseudoflow. 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, as the packet moves from a 6LSA domain to an 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. If the packet is not to be assigned to a FEC, as in the case when the packet exits a 6LSA network and if it is a subsequent packet, the non-zero label is removed and in its place the original non-6LSA label, a zero value label, is inserted as needed. 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. Chakravorty Expires - December 2004 [Page 10]
draft-chakravorty-6lsa-00.txt August 2004 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 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 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. 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, if it is 1 (one), 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, often called the forwarding table in the 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. ò 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 a FEC is based on known attributes of the packet or on externally applied constraints. The former may be 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 Expires - December 2004 [Page 11]
draft-chakravorty-6lsa-00.txt August 2004 special bit encoding in the body of the message past the protocol headers. The latter may be 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 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. 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 has end-to-end, multiple-hop significance within the 6LSA. A 6LSP is thus identified with a sequence of 6LSAs, <R1,àà,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 packet is a lead packet; ò 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, a 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 on the next-hop address unless there is penultimate 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 in each of the 6LSR on the 6LSP. In this regard, 6LSP closely resembles a virtual circuit (VC) in ATM, and LSP in MPLS. Chakravorty Expires - December 2004 [Page 12]
draft-chakravorty-6lsa-00.txt August 2004 |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. 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 be many ingress, intermediate and egress 6LSRs in a 6LSA. 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. +--------------------------------------+ Non-6LSA domain | | | 6LSA domain | | | Chakravorty Expires - December 2004 [Page 13]
draft-chakravorty-6lsa-00.txt August 2004 | | | | +-+-+ 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 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. Chakravorty Expires - December 2004 [Page 14]
draft-chakravorty-6lsa-00.txt August 2004 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 within the parameters algorithm in which the bit field values are within the parameters specified in Section 6.1, Label. 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 the Locally Generated Label Model mechanism 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 such as that present 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. 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. Current protocols that allow a 20-bit label distribution and do not violate any of this 6LSA specifications 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 the ô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 - December 2004 [Page 15]
draft-chakravorty-6lsa-00.txt August 2004 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. 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 +---- Chakravorty Expires - December 2004 [Page 16]
draft-chakravorty-6lsa-00.txt August 2004 | | | | +-+-+ +---+ |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. +---+ +---+ | | | | ------+ A | | C +------ ____ | | | | +-+-+ +-+-+ | | | | L/F2 | +---------+ | | | +-+-+ | L/F1 | | +--------------------+ B +---- | | +-+-+ Same Label for Multiple Flows into Different Interfaces Figure 5. 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 LDP is used, or if the 6LSA locally distributed label model carries a specific lead packet identifier bit, such as the PID-representative bit as in the Reuse Label model. | | |L/F4 +---+ +-+-+ +---+ Chakravorty Expires - December 2004 [Page 17]
draft-chakravorty-6lsa-00.txt August 2004 | | 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 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 here in this document. 7.6 Label Swapping Label swapping or 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 forwarding the packet. However, when the swapping involves only incoming label replacement with an outgoing label, it is called label switching, which is typically is 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 ouside 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 - December 2004 [Page 18]
draft-chakravorty-6lsa-00.txt August 2004 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 are related 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 with one or more other networking domains such that 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 the locally generated 0 (zero) label and the NTL and subsequent packets with the unique label, the former is defined as a flow, while the latter, a pseudoflow in this specification. ò 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. Chakravorty Expires - December 2004 [Page 19]
draft-chakravorty-6lsa-00.txt August 2004 ò 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 the egress 6LSR peering with some other network router, FEC does not exist since the packets are transmitted out to the other network; the packets are forwarded 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 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 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. +-----------------------------------------------------+ | | | | | Ingress Intermdt. Egress | | 6LSR 6LSR 6LSR | | +-------+ +-------+ +-------+ | | | | | | | | | ---|--+ +----------+ +----------+ +----|--- | | A | | C | | B | | ---|--+ +----------+ +----------+ +----|--- | | | | | | | | | +-------+ +-------+ +-------+ | | | | | | | +-----------------------------------------------------+ Packet Processing Figure 7. Chakravorty Expires - December 2004 [Page 20]
draft-chakravorty-6lsa-00.txt August 2004 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. 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. ----------------------------------------------------------------------_ _ | | | | | | 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 ---> | 1 |--------->| 1 |--------->| 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. ---------------------------------------------------------------------- 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 ---> | 1 |--------->| 1 |--------->| 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 - December 2004 [Page 21]
draft-chakravorty-6lsa-00.txt August 2004 All other packets in this flow have the same characteristics; following flows are similar to this flow. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Label Swapping for Non-Merging Flows Figure 8. 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 ¡ 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. 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, 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, bind the outgoing label to 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 the third or later packet, that is, a subsequent packet in the flow, switch the incoming label with the outgoing label and forward the packet. Chakravorty Expires - December 2004 [Page 22]
draft-chakravorty-6lsa-00.txt August 2004 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; acquire an outgoing label, bind the outgoing label to 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 with the incoming label; there is no swapping of labels. ii) If there is a match for only the incoming label, i.e., if no outgoing label exists, then this is a lead packet; acquire an outgoing label, bind the outgoing label to 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 labels. iii)If there is a match, for both the label and the interface, this is an NTL or a subsequent packet in this flow. Switch the incoming label with the outgoing label and forward the packet out. 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 including 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 swapping of incoming with the outgoing labels if the incoming label is 0 (zero) otherwise swap the incoming label with 0 (zero) label for the peering best-effort network. ii) If there is a match for only the incoming label and not the interface, then 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 route for the outgoing packet, and forward the packet out; there is no swapping of labels if the incoming label is 0 (zero) otherwise swap the incoming label with 0 (zero) label for the peering best-effort network. 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; switch the incoming label with 0 (zero) label and forward the packet out for the peering best-effort network based on the next-hop route from the switching table. 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 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; acquire an outgoing label which is unique for the outgoing interface, bind the outgoing label to the pre-selected FEC for this flow, make switching table entry for this packet including the labels and the PID value of 0 (zero) for the outgoing packet and forward the packet out; there is no swapping of incoming with the outgoing labels. Chakravorty Expires - December 2004 [Page 23]
draft-chakravorty-6lsa-00.txt August 2004 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. 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; acquire an outgoing label which is unique, bind the outgoing label to 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 and forward the packet out; there is no swapping of incoming with the outgoing labels. 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; acquire an outgoing label, bind the outgoing label to the pre-selected FEC for this flow, make switching table entry for this packet including the labels and the PID value of 0 (zero) for the outgoing packet and forward the packet out; there is no swapping of incoming with the outgoing labels. 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; acquire a unique outgoing label, bind the outgoing label to the pre-selected FEC for this flow, make switching table entry for this packet including the labels and the PID value to 1 (one) if it was a 0 (zero) and forward the packet out after swapping incoming label with the outgoing label. ¡ 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, look up the next-hop route and make switching table entry for this packet including the label, the PID value of 0 (zero), and route for the outgoing packet, forward the packet out; swap the incoming label with 0 (zero) outgoing label if the incoming label is non-zero. 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; look up the next-hop route and make switching table entry for this packet including the label, the PID value of 0 (zero), and route for the outgoing packet, forward the packet out; swap the incoming label with the 0 (zero) outgoing label if the incoming label is non-zero. 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 ¡ o 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 - December 2004 [Page 24]
draft-chakravorty-6lsa-00.txt August 2004 o 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. 7.7.3 Packet Processing in the Distributed Label Model Packet processing in this model is out of scope of this specification. This if 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 be discarded after the lead packet is forwarded in a pseudoflow. Invalid labels may not include a zero-labeled packet. 7.11.1 LSP 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 LSP 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. Chakravorty Expires - December 2004 [Page 25]
draft-chakravorty-6lsa-00.txt August 2004 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. 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 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 Chakravorty Expires - December 2004 [Page 26]
draft-chakravorty-6lsa-00.txt August 2004 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 mutlicast addressing. Whenever a 6LSR is a node in any mutlicast tree, such a tree may be a 6LSA, a subset of 6LSA or a part of 6LSA. When a mutlicast packet arrives in a multicast tree 6LSR where the subnet is a part or whole of 6SLA, the 6LSR binds the packet to a FEC which has mutlicast 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 mutlicast forwarding. 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 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 References a. Rosen, E. Viswanathan, A. and Callon, R., ôMultiprotocol Label Switching Architecture,ö RFC 3031, January 2001 b. J. Rahjahalme, et al, ôIPv6 Flow Label Specification,ö RFC 3697, March 2004 c. Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Chakravorty Expires - December 2004 [Page 27]
draft-chakravorty-6lsa-00.txt August 2004 d. Hinden, R. and Deering, S., "IPv6 Multicast Address Assignments", RFC 2375, July 1998 e. Awduche, D., et al, ôRequirements for Traffic Engineering Over MPLSÆ, RFC 2702, September 1999 f. Awduche, D., et al, ôOverview and Principles of Internet Traffic Engineeringö, RFC 3272, May 2002 g. Agarwal, P. and Akyol B., Time to Live (TTL) Processing in MPLS Networks, RFC 3443, January 2003 h. Hinden, R. and Deering, S., ôIPv6 Addressing Architectureö, RFC 3513, April 2003 10. Acknowledgements 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 acknowledges overall management support for implementation of this protocol given by Jim Providakes (MITRE). 11. AuthorÆs Addresses Question on this draft can be directed to Sham Chakravorty MITRE Corporation 1575 Colshire Dr. McLean, VA 22102 Email: schakra@mitre.org 12. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all the rights. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Funding for the RFC editor function is currently provided by the Internet Society. Chakravorty Expires - December 2004 [Page 28]