IPNG Working Group V. Roesler Internet Draft UNISINOS Document: draft-roesler-ipngwg-ipngls-00.txt L. Balbinot Expiration Date: March 2002 UFRGS M. Andrade UNISINOS September, 2001 IPNGLS - IP Next Generation Label Switching STATUS OF THIS MEMO: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document proposes the forwarding of IPv6 packets using label switching techniques, with the same advantages of the Multiprotocol Label Switching (MPLS) architecture. The document proposes the mapping of all MPLS header fields into the IPv6 header, raising several advantages like the simplicity of the model, the decrease of overhead, and others. This mapping was called IP Next Generation Label Switching, or just IPngLS, and can work concurrently with MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets are forwarded with MPLS. Roesler, Balbinot & Andrade [Page 1] INTERNET-DRAFT IPNGLS September 2001 Table of Contents 1. Introduction .................................................. 3 2. Related Work .................................................. 5 3. Mapping Details ............................................... 5 3.1. IPv6 and MPLS Headers .................................... 7 3.2. Mapping Label to Flow Label .............................. 8 3.3. Mapping EXP to Traffic Class ............................. 8 3.4. Mapping S to Hop By Hop .................................. 9 3.5. Mapping TTL to Hop Limit ................................ 11 4. Security Considerations ...................................... 12 5. References ................................................... 12 Appendix A. Implementation example .............................. 13 Appendix A.1. Core LSR .......................................... 14 Appendix A.2. Edge Ingress LSR .................................. 15 Appendix A.3. Edge Egress LSR ................................... 16 Authors' Addresses .............................................. 17 Roesler, Balbinot & Andrade [Page 2] INTERNET-DRAFT IPNGLS September 2001 1. Introduction Label switching was first developed to boost the throughput of routers by bringing layer 2 packet forwarding speeds up to layer 3. After faster ASIC-based routers arrived, the forwarding speed concern was not so important anymore. However, other applications for label switching arose, such as traffic engineering, which is concerned with the task of determining the path of a packet between source and destination as well as with the association of quality of service (QoS) characteristics to several traffic classes. Besides that, label switching enables the creation of tunnels (namely VPNs, or Virtual Private Networks) in a very straightforward manner, and it can also simplify the network by bringing many control plane functions to layer 3. Currently, label switching is being proposed by the Multiprotocol Label Switching (MPLS) working group (see http://www.ietf.org/html.charters/ mplscharter.html) and consists on adding a new header between layer 2 and layer 3 (also known as the "shim" header) of the datagram. The main part of this header is the label, which works as an index for a forwarding table in the routers. Routers use these labels to determine the egress interface and the value of the new label (whose semantics is only known by the next router in the path towards the destination). This is a familiar concept for those used to circuit-switched telecommunication networks. NOTE: This document only deals with the mapping of the MPLS shim header to IPv6 headers and is not concerned with other protocols, such as ATM or Frame Relay. On IP networks the MPLS shim header is necessary given that the IPv4 header [1] cannot carry all the data needed by MPLS. That makes it necessary for routers to handle a new header -- the shim -- located at the so called "layer 2.5", thus increasing the complexity of the protocol stack. With IPv6, however, there is one header field called Flow Label that can be used to hold the MPLS label. This field can provide the same functionality of the MPLS shim label without increasing the complexity of the model; besides, it is able to save some octets. All other MPLS shim header fields can be completely mapped to IPv6 headers as it is described further in this paper. This document specifies IPngLS (IP Next Generation Label Switching.) IPngLS is a proposal to migrate all functionalities provided by the MPLS shim header to the IPv6 header. Naturally, IPngLS stands on the fact that, in the future, IPv6 will be the successor of IPv4, thereby becoming the dominant layer 3 protocol. However, even tough both protocols coexist during some time, the mapping described here Roesler, Balbinot & Andrade [Page 3] INTERNET-DRAFT IPNGLS September 2001 continues to be valid, since routers will only have to look at the layer 2 field that indicates which is the upper layer protocol. Based on this information, routers know what to expect: an MPLS header (unicast type = 8847h and multicast type = 8848h) [2], an IPv4 header (type = 8000h) or an IPv6 header (type = 86DDh) [3]. Some advantages of IPngLS, i.e. the integration of MPLS and IPv6, are: 1. Descrease of complexity: It eliminates an extra header in the system. In fact, there is no reason to use a new header if the original one can fulfill all the tasks. 2. Decrease of overhead: Saves 4 octets in all IPv6 packets when there are no tunnels in use, if compared to MPLS. One may say that it is a trivial advantage, but considering an average packet size of 500 octets, the MPLS shim header consumes up to 0.8% of the total bandwidth (that is about 20 Mbps of overhead in a 2.4 Gbps link). 3. No extra QoS mappings: MPLS reserves only 3 bits to classify packets into QoS classes while IPv6 is fully compatible with the Differentiated Services (Diffserv) [4] philosophy, avoiding the 3-to-6 bits mapping proposed in [5]. 4. Straightforward TTL handling: MPLS introduces a new TTL (time-to-live) field, apart from the IP header. This pushes a new complexity to MPLS-enabled routers, that must update the TTL field of the IP header at the border of the MPLS network as well as to check if the TTL field is likely to expire inside this network. All packets that have a TTL too low to cross the label switched path (LSP) may be forwarded using the conventional hop-by-hop forwarding. With IPngLS none of these procedures are necessary since the only TTL in use is the IPv6's TTL, thus simplifying the system. 5. Layer 3 switching at layer 2 speeds: IPngLS enables layer 3 switching, but with the switching speed and agility of layer 2 technologies. It also has the advantage of using traffic engineering with constraint-based routing. Of course, IPngLS has some drawbacks. The most evident is that it is only suitable for IPv6 networks, still needing MPLS to interoperate with IPv4 networks. That will dwindle as IPv6 becomes the dominant Internet protocol. Questions regarding multicast and label switching, label distribution, traffic balancing, integration with ATM and Frame Relay (unique control plane), and others, have specific studies throughout the MPLS working group and are not in the focus of our research, which is only concerned with the MPLS-to-IPv6 mapping. Roesler, Balbinot & Andrade [Page 4] INTERNET-DRAFT IPNGLS September 2001 2. Related Work The integration of IPv6 and label switching technologies is not a novel approach. In 1996, Baker and Rekhter published an Internet-Draft [6] regarding this subject, but it expired on April 1997 and no further publications were made. At that time, label switching and IPv6 were emerging technologies and their role in future networks was not very clear. The draft is very concise and does not deal with questions regarding tunnels, QoS, multicast, and so forth. Baker's proposal imploded a long discussion thread on the IETF's IPng Working Group (see http://www.ietf.org/html.charters/ipngwg-charter.html) mailing list, but that ceased after a while and the subject was not brought to discussion anymore. Months later, Rekhter et al. published RFC 2105 [7], which specifies Cisco's Tag Switching Architecture, the kick off for label switching technologies in IP networks. The RFC is very brief when it comes to the use of the IPv6 Flow Label field to transport the packet's "tag". Actually, there is only one small phrase saying that the "tag" may be encapsulated as a part of the network layer, "using the Flow Label field in IPv6 with appropriately modified semantics" [7]. 3. Mapping Details of IPngLS To show the feasibility of IPngLS we must first analyse the IPv6 and the MPLS headers, as well as all header fields involved in the mapping process. First, it is important to note that IPngLS does not have to read and process all IPv6 header bits. Routers running IPngLS must read only the first 64 bits (two 32-bit words), against the 32 bits from the MPLS shim. Second, it is also very important to remember that all the research being done with MPLS is kept (e.g. the Label Distribution Protocol [8].) The only difference is that instead of using the MPLS shim header, the label is inserted directly inside the very same IPv6 header. The mapping inside an IPngLS network is quite simple: whenever a packet arrives at an IPngLS-enabled edge router, the router must analyse whether the layer 3 protocol is IPv6 or not. If positive, it unpacks only its first two 32-bit words and checks the Flow Label field: if it is different from zero then it means that it represents a label. This label can therefore be used as an index to a forwarding table where the router can get the egress interface and the new label that must be written into the packet's Flow Label field. As a protocol use-case example in an end-to-end transmission, consider the topology shown on Figure 1. In this example the transmitter sends packets through its subnetwork with the Flow Label Roesler, Balbinot & Andrade [Page 5] INTERNET-DRAFT IPNGLS September 2001 field set to zero. Local routers that do not implement IPngLS will forward the packets using conventional routing and will not touch the Flow Label field. To get some degree of QoS from the network until the packets reach the default router the transmitter may use layer 2 QoS techniques, such as 802.1p [9]. The default router may, in turn, map the layer 2-specific QoS parameters to Diffserv or Intserv (see http://www.ietf.org/html.charters/intservcharter.html), thus providing QoS until the packets reach the edge router (ingress for the IPngLS network.) The QoS marking process may use several parameters, including type of protocol, source and destination addresses, etc. +-------------+ +-------------+ +---------------+ | Transmitter |----->| Def. Router |----->| Legacy Router | +-------------+ +-------------+ +---------------+ | +---------------------+ | LSR (ingress router)| +---------------------+ | +-------------------+ | LSR (core router) | +-------------------+ | +-------------------+ | LSR (core router) | +-------------------+ | +---------------------+ | LSR (egress router) | +---------------------+ | +-------------+ +-------------+ +---------------+ | Receiver |<-----| Def. Router |<-----| Legacy Router | +-------------+ +-------------+ +---------------+ Figure 1. IPngLS in practice When the packet arrives at the ingress router for the IPngLS-enabled network the Flow Label field must be equal to zero. Since at this moment the packet is about to enter a label switched path (LSP), it must receive a label. The ingress router may consider all flows coming from the transmitter's network as being a single aggregated flow, or it can split the flows according to some enterprise-specific parameters, but that is beyond the scope of this document. If an aggregated flow already exists to the destination of a packet and if the packet conforms to existing admission control policies then all the ingress router has got to do is add the label, update the packet's DS field (if QoS is in use) and forward it to the correct egress interface. Roesler, Balbinot & Andrade [Page 6] INTERNET-DRAFT IPNGLS September 2001 But, if the packet characterizes a new flow then a label distribution protocol (e.g. LDP [8]) should be used to make the proper network configuration for this flow. With IPngLS the last router in the IPngLS network must set the Flow Label field back to zero, thereby indicating that the packet must be forwarded via conventional forwarding until it reaches the receiver or another IPngLS edge router. The egress router may also change the DS field to fit the QoS guarantees according to the receiver's network policies. 3.1. IPv6 and MPLS headers Figure 2 shows the IPv6 header [10] and Figure 3 shows the MPLS shim header [2]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. IPv6 header. The value of the Version field is 6 and is used to check whether the protocol is really IPv6. The Traffic Class field is used to distinguish between different classes or priorities of IPv6 packets, being conformant to the differentiated services architecture. The Payload Length value is the size, in octets, of the IPv6 packet following the main header (including the extension headers.) The Next header field identifies the type of the next header, which can be an extension header or an upper layer protocol. The Hop Limit is decreased at each hop and the packet is discarded when its value reaches zero. The Source and Destination fields are the packet's IP Roesler, Balbinot & Andrade [Page 7] INTERNET-DRAFT IPNGLS September 2001 originator and recipient, respectively, and are not used by IPngLS. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. MPLS shim header. The MPLS shim header has a total of 32 bits. The "Label" field is used as an index by intermediary routers. This index points to an entry in a forwarding table that contains the packet egress interface and the new label that must be inserted into the shim. The "Exp" field (Experimental Use) is likely to be used as a packet priority indicator similar to the mechanism used by 802.1p. The "S" field works as an indicator for the last stacked header (if tunnels are in use), i.e. the last shim header in the stack has the "S" bit set to zero. At last, the "TTL" field is used to avoid network loops, representing the packet's time-to-live inside the MPLS network. As the paper advances, it will become clear how the MPLS shim header can be eliminated through the mapping of its fields to the first two 32-bit words of the IPv6 header. The mapping of each individual field is described in the next sections. 3.2. Mapping "Label" to "Flow Label" The mapping of the "Label" field from the MPLS shim header into the "Flow Label" field from the IPv6 header can be done on a 1-to-1 basis since both are 20-bit long. Therefore, the semantic of the label is kept unchanged. As mentioned before, if this field is equal to zero then the router must proceed with the conventional forwarding procedure. Otherwise, its value must be used as index for a forwarding table. If the router detects an invalid Flow Label value, i.e. different from zero but not listed in the forwarding table, then the field must be set to zero to avoid error propagation. Whenever this happens, these packets must be forwarded using conventional forwarding. 3.3. Mapping "EXP" to "Traffic Class" The "Exp" field raises one drawback of MPLS, that is the use of only 3 bits to express QoS on the network core. On the other hand, IPv4 and IPv6 are using 6 bits to do that with the "TOS" (Type of Service) and "Traffic Class" header fields, respectively. Thus, both protocols conform to Diffserv [4]. Roesler, Balbinot & Andrade [Page 8] INTERNET-DRAFT IPNGLS September 2001 With IPngLS it is not necessary to worry about the mapping of the 3 bits from the "Exp" field into the 6 bits of the "DS" field [5] since the mapping is made on a 1-to-1 basis. 3.4. Mapping S to Hop-by-Hop Options The mapping of the "S" field is more complex because it is MPLS-specific and has no equivalent field in the IPv6 header. The "S" field is used to create tunnels inside MPLS-enabled networks. At the beginning of a tunnel, the "S" bit is set to one and a new shim header is pushed into the packet. At the egress router of the tunnel, the extra shim header is popped and the previous one is used. Each shim header needs 4 octets from the packet, what increases the system overhead. IPv6 supports various extension headers [10] that allow the dynamic extension of header data fields and functions. One of these headers is the Hop-by-Hop Options (Next Header = 0) that must be analysed by each hop along the route and can, therefore, be used by IPngLS. Thus, for instance, when a packet arrives at the ingress router of a tunnel, this router creates a hop-by-hop extension header, moves the original label from the packet's header to the extension header and writes the label used by the tunnel in the Flow Label field. This enables routers along the tunnel to analyse only the first two 32-bit words of the IPv6 header, as if there was no tunnel at all, thus keeping the same forwarding speed and agility of a packet without the extension header. Note that the extension header grows dynamically as more storage space for pushing labels is needed. Looking at the big picture one may note the "next hop" of an ingress IPngLS router is the egress IPngLS router: all routers between these two are "invisible" (e.g. traceroute will not show them) because they only switch packets based on labels. Therefore, these routers must not look at IPv6 extension headers. Figure 4 shows the hop-by-hop extension header created for IPngLS when only one tunnel (LSP) exists between source and destination. Each tunnel demands 4 octets (pointed out by the "Opt Data Len" field.) From these, 20 bits are used to store the original Flow Label and the remaining 12 bits are marked as reserved for future use. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Flow Label | Future Use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. IPngLS extension header for one tunnel. Roesler, Balbinot & Andrade [Page 9] INTERNET-DRAFT IPNGLS September 2001 The meaning of each one of these fields is: Next Header 8 bits: identifies the type of the next header, that can be another extension header or an upper layer header (e.g., TCP.) Hdr Ext Len 8 bits: identifies the amount of 8-octet groups in the extension header, not including the first group [10]. On Figure 4, Hdr Ext Len = 0 since the first 8-octet group is large enough to handle one tunnel. Option Type 8 bits: identifies the type of the option field. IPngLS suggests the type 83h (131 decimal.) In this value the highest-order two bits are 10, indicating that if an intermediary router does not recognizes this option then it should return an ICMPv6 message back to the source address. The value 83h depends on the approval of the IETF. Opt Data Len 8 bits: length of the option data field, in octets. If only one tunnel is in use then Opt Data Len = 4. Original Flow Label 20 bits: the label that was in the IPv6 header. Every time a tunnel is created, the Flow Label field from the packet is copied over this field and the IPv6 header receives the new label for the tunnel. Note that there is a label switch every time a tunnel starts and ends. Future Use 12 bits: reserved for future use. Suggested uses are Diffserv code-point storage, and explicit congestion notification (ECN) [11] mechanisms. As shown, the total amount of octets used by a single tunnel is 8. In this case, the overhead introduced by IPngLS is the same as for MPLS (with two shim headers.) The same is true for any odd number of tunnels. For an even number of tunnels, the overhead introduced by IPngLS is 4 octets higher than MPLS, as shown on Figure 5, where a 4-tunnel header is presented. This is due to IPv6's alignment requirements, as described in RFC 2460 [10]. In this case, IPngLS needs 24 octets while MPLS needs only 20. Roesler, Balbinot & Andrade [Page 10] INTERNET-DRAFT IPNGLS September 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Flow Label | Future Use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label for Tunnel 1 | Future Use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label for Tunnel 2 | Future Use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label for Tunnel 3 | Future Use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. IPngLS extension header for four tunnels. The meaning of the Next Header and Option Type fields is the same as described before. Since we need two extra 8-octet groups to hold all labels, Hdr Ext Len must be set to 2 (remember not to count the first 8-octet group.) There are four labels in the stack and each one takes 4 octets, what leads to Opt Data Len = 16. The Flow Label fields hold the labels. The label at the top of the stack is the label for Tunnel 3. Routers know the depth of the stack by looking at the Opt Data Len field. Note that the IPv6 header's Flow Label field (not shown on the figure) contains the label for Tunnel 4. The Future Use field is 12-bit long to fit the word alignment of the header. Note that when an even number of labels are stacked, there will always be one 32-bit word left unused at the very end of the header because extension header space can only be allocated in 8-octet chunks. To keep the header aligned, some padding bits must be inserted. Since we need an 4-octet alignment, we must use a PADN (Option = 1) with Opt Data Len = 2, where the data is filled with zeros. 3.5. Mapping TTL to Hop Limit The "TTL" field can also be mapped on a 1-to-1 basis into the "Hop Limit" IPv6 header field. If compared to MPLS, IPngLS handles this field in a much simpler way. With MPLS there are two distinct TTL fields: one at the shim header and another at the IP header. The egress MPLS router must subtract the number of hops along the LSP from the packet's TTL field [12]. If the TTL expires in transit then the packet must not be sent via MPLS and may, therefore, be forwarded using conventional forwarding. With IPngLS that is not necessary given that the IPv6 Hop Limit header field is decreased at each actual hop, just like if no label switching mechanism was in action. Thus, there is no need to care about how many hops a packet will flow through nor to subtract and Roesler, Balbinot & Andrade [Page 11] INTERNET-DRAFT IPNGLS September 2001 update the IP header field at the egress router, even tough that is possible. Thus, this approach supports traceroute functionality, multicast traffic scoping and loop suppression, which is the original function of this field. 4. Security Considerations There are no Security Considerations, as this document specifies only the mapping of MPLS in IPv6. 5. References [1] J. Postel. "Internet Protocol". ISI, RFC 791, September 1981. [2] E. Rosen et al.. "MPLS Label Stack Encoding". Cisco Systems, Juniper Networks, Procket Networks, TranSwitch Corp., RFC 3032, January 2001. [3] C. Huitema. "Routing in the Internet", 2nd Ed. New Jersey: Prentice Hall, 2000. [4] K. Nichols et al.. "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers". Cisco Systems, Torrent Networking Technologies, EMC Corporation, RFC 2474, December 1998. [5] F. Le Faucheur et al. "MPLS Support of Differentiated Services". Cisco Systems, PMC-Sierra Inc., Nokia, Axiowave Networks, Alcatel, Telia Finland, Internet-Draft (work in progress), draft-ietf-mpls-diff-ext-09.txt, April 2001. [6] F. Baker and Y. Rekhter. "Use of Flow Label for Tag Switching". Cisco Systems, Internet-Draft (expired), draft-baker-flow-label-00.txt, October 1996. [7] Y. Rekhter et al. "Cisco Systems' Tag Switching Architecture Overview". Cisco Systems Inc., RFC 2105, February 1997. [8] L. Andersson et al. "LDP Specification". Nortel Networks, Ennovate Networks, IBM Corp., PhotonEx Corp., Cisco Systems, RFC 3036, January 2001. [9] IEEE. "IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges". The Institute of Electrical and Electronics Engineers, Standard 802.1D, 1998. [10] S. Deering and R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification". Cisco Systems, Nokia, RFC 2460, December 1998. Roesler, Balbinot & Andrade [Page 12] INTERNET-DRAFT IPNGLS September 2001 [11] K. Ramakrishnan and S. Floyd. "A Proposal to add Explicit Congestion Notification (ECN) to IP". AT&T Labs Research, LBLN, RFC 2481, January 1999. [12] E. Rosen, A. Viswanathan, and R. Callon. "Multiprotocol Label Switching Architecture". Cisco Systems, Force10 Networks, Juniper Networks, RFC 3031, January 2001. APPENDIX A. Implementation example There are edge LSR's and core LSR's. The former can be of ingress or egress. In order to find out which LSR interfaces are egress interfaces, the router must look at the FEC table during the connection setup process. A special flag is set at the forwarding table entries of egress LSR's. There are two main data structures in this implementation example, which will be simplified herein for the sake of simplicity. Lets call them struct "P" (representing the IPv6 header data structure) and struct "N" (representing an entry at the IPngLS forwarding table.) The latter has two main components: N.FlowLabel and N.IfOut. [Incoming packet P at interface I] | v (True) if(core_router(I)==1) -----------------+ | | |(False) | | | | v (True) | if(P.FlowLabel!=0)-------> [Core()] | | | |(False) | v | [Conventional IPv6 Routing] | | v (True) if(ingress_router(I)==1)--------->[EdgeIngress()] | |(False) v [EdgeEgress()] Figure 6. IPngLS entry point flowchart Figure 6 shows a flowchart of the implementation's entry point. Whenever an IPv6 packet arrives at an LSR interface, the kernel must check whether that interface is a core LSR interface or an edge LSR Roesler, Balbinot & Andrade [Page 13] INTERNET-DRAFT IPNGLS September 2001 interface. If it is a core LSR interface (core_router == 1) and P.FlowLabel is different from 0 then all the remaining tasks are taken care by the Core() function. If P.FlowLabel is set to 0 at a core LSR interface then the packet must be forwarded using the conventional IPv6 routing procedure. If the value of ingress_router is equal to 1 then it means that the router is an ingress router for that interface. In this case, all the remaining tasks are accomplished by the EdgeIngress() function. Otherwise, the packet may be an egress packet, so the EdgeEgress() function is called. A.1. Core LSR Packet handling at the network core is a simpler task, as shown by the Core() function flowchart in Figure 7. When a packet arrives, the getNext() function is called and returns the data structure "N" for the next hop of the packet. If some problem occurs, e.g. for some reason there was no label in the forwarding table, then N.FlowLabel will be set to 0. If that happens then the conventional IPv6 forwarding take place. The packet's FlowLabel field (P.FlowLabel) is set to 0 for safety. [Core()] | v [N = getNext(P)] | v (True) if(N.FlowLabel != 0)------->[P.hopLimit--] | | |(False) v (True) | if(P.HopLimit==0)------>[ICMPv6_Error()] | | | |(False) | v | [P.FlowLabel = N.FlowLabel] | [ SendPacket(P,N.IfOut) ] | v [P.FlowLabel = 0] | v [Conventional IPv6 Routing] Figure 7. Core LSR flowchart But, if N.FlowLabel is not 0 then the packet's Hop Limit field is decreased (P.HopLimit--). If P.HopLimit reaches 0 then an ICMPv6 error message is sent back to the source. Otherwise, the packet is Roesler, Balbinot & Andrade [Page 14] INTERNET-DRAFT IPNGLS September 2001 ready to be delivered through the egress interface (N.IfOut) with the new label (N.FlowLabel). A.2. Edge Ingress LSR The main function of an ingress LSR is to classify a packet flow into specific LSP's. Currently, our implementation is not working with any label distribution mechanism (e.g. the LDP [8]) and all configuration must be done manually, which is not a complicated task for small test environments. [EdgeIngress()] | v [N=getNew(P)] | v (True) if(N.FlowLabel != 0) --------->[P.hopLimit--] | | |(False) v (True) | if(P.HopLimit == 0)------>[ICPMv6_Erro()] | | | |(False) | | | v (True) | if(Tunneling(I) == 1)------->[CreateTunnel()] | | | | |(False) | | | | | |<--------------+ | v | [P.FlowLabel = N.FlowLabel] | [ SendPacket(P,N.ifOut) ] v [P.FlowLabel = 0] | | v [Conventional IPv6 Routing] Figure 8. Edge ingress LSR flowchart The flowchart of the ingress LSR algorithm is shown on Figure 8. Most of the complexity from the algorithm is hidden inside the getNew() function. This function is responsible for triggering the setup of a new LSP. If the Flow Label returned by getNew() (i.e. N.FlowLabel) is equal to 0 then the packet must be delivered using the conventional IPv6 forwarding procedure. The Flow Label field of the packet is set to 0 for safety. Roesler, Balbinot & Andrade [Page 15] INTERNET-DRAFT IPNGLS September 2001 If the router has got a valid label then the Hop Limit field is decreased and an ICMPv6 error message is sent back to the source if it reaches 0. The LSR checks whether the interface supports tunneling (i.e. label stacking.) If it does support tunneling (tunneling == 1) then the CreateTunnel() function is called to create or modifiy the existing IPv6 extension header. Nevertheless, the packet is sent through the egress interface (N.IfOut) with the correct label (N.FlowLabel). A.3. Edge Egress LSR By looking at a special flag in the forwarding table an LSR knows which LSP's or tunnels should be terminated. This special flag is set at connection setup time and may be due to fact that: 1. the LSR is the egress point for a domain via a tunnel, hence it must be terminated; 2. the FEC specifies a host or network prefix directly connected to the LSR interface; 3. the next hop is outside the IPngLS domain boundary. The flowchart for this algorithm is shown in Figure 9. A special function called getEgressType() tells whether the LSR must release a tunnel or terminate an LSP. A tunnel is released with the ReleaseTunnel() function. After a tunnel is released, the packet is delivered to the Core() function for further processing. If a single LSP must be terminated then the Flow Label field is set to 0 and the packet is sent to the conventional IPv6 forwarding mechanism. [EdgeEgress()] | v [T = getEgressType(P)] | v (True) if(T == Tunnel) -------->[ReleaseTunnel()] | | |(False) v | [Core()] | v [P.FlowLabel = 0] | v [Conventional IPv6 Routing] Figure 9. Edge egress LSR flowchart Roesler, Balbinot & Andrade [Page 16] INTERNET-DRAFT IPNGLS September 2001 Author's Address Valter Roesler UNISINOS - University of Sinos River's Valley Unisinos Ave., 950 Sao Leopoldo, RS, Brazil roesler@exatas.unisinos.br Luis Felipe Balbinot UFRGS - Federal University of Rio Grande do Sul Bento Gon‡alves Ave., 9500 Porto Alegre, RS, Brazil hades@inf.ufrgs.br Maiko de Andrade UNISINOS - University of Sinos River's Valley Unisinos Ave., 950 Sao Leopoldo, RS, Brazil maiko@exatas.unisinos.br Document: draft-ietf-ipngwg-ipngls-00.txt Expiration Date: March 2002 Roesler, Balbinot & Andrade [Page 17]