MPLS Working Group Nabil Bitar Internet Draft Verizon Intended status: Standards Track Expires: April 24, 2012 Himanshu Shah Ciena George Swallow Cisco October 24, 2011 ISIS MPLS Explicit NULL Label draft-bitar-mpls-isis-explicit-null-label-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 24,2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Bitar, et al. Expires April 24, 2012 [Page 1] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract There is need to support IP interfaces on the top of GMPLS packet Label Switched Paths (LSPs), and enable IP routing (e.g., OSPF-TE, ISIS-TE) and MPLS protocols on these interfaces. Traffic on an IP/MPLS interface can be user traffic or control traffic. In addition, it can be MPLS, IP or ISIS. Multiplexing IP and MPLS packets over the same LSP is supported in the current MPLS architecture. However, multiplexing IP, MPLS, and ISIS packets over the same LSP is not currently supported. This draft proposes the definition of an explicit ISIS NULL label to enable this type of multiplexing to take place. Table of Contents 1. Introduction..............................................2 2. Operational Procedures....................................3 3. ISIS Packet Encapsulation format..........................5 4. IANA Consideration........................................6 5. Security Considerations...................................6 6. References................................................6 6.1. Normative References.................................6 6.2. Informative References...............................6 1. Introduction RFC 4206 [RFC 4206] defines the concept of a forwarding adjacency (FA) built on a Traffic Engineered (TE) LSP. An FA can be unidirectional and signaled via RSVP-TE, or bidirectional and signaled via RSVP-TE with GMPLS extensions. It is signaled over the same network on which it is routed. An FA is included in the network IGP link state database as a TE link but used only for forwarding. That is, it is never used to establish a routing adjacency. Routing adjacencies are necessary in a link-state IGP network for topology discovery and link-state information dissemination. FAs capitalize on the existence of routing adjacencies, and routers make use of the topology information exchanged over these adjacencies to establish the FAs. Bitar, et al. Expires April 24, 2012 [Page 2] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 In MPLS-TP, client network islands that belong to the same IGP are interconnected over an MPLS-TP [RFC 5921] server network in an overlay model. A client network island is connected to the MPLS-TP network via a border client router. Two client border-routers need to form a routing adjacency over a GMPLS LSP signaled through the MPLS-TP network via GMPLS UNI signaling. The GMPLS UNI is the interface between the client border node and the connected MPLS-TP network edge. This document introduces the explicit ISIS NULL label that enables the establishment of an ISIS(-TE) routing adjacency over a GMPLS LSP, and to treat that routing adjacency as any IP adjacency, enabling MPLS signaling, IP and MPLS multicast signaling/routing, and MPLS and IP forwarding over that adjacency. 2. Operational Procedures <-------- ISIS, RSVP-TE, LDP, PIM, LDP, BFD ------> <---------- Tunnel LSP: Routing Adjacency --------> <---Transport LSP---> GMPLS UNI GMPLS UNI +-+--+ +----+ +----+ +----+ | R1 |+-------+| PE1|+-----------------+|PE2 |+-----+| R2 | +----+ +----+ +----+ +----+ Figure 1: Reference Model for GMPLS LSP Tunnel as an IP interface Figure 1 depicts a reference model for the GMPLS UNI and GMPLS LSP routing adjacency, referred to as tunnel LSP. R1 connects to the MPLS transport network via a GMPLS UNI interface between R1 and PE1. R2 connects to the MPLS transport network via a GMPLS UNI interface between R2 and PE2. A GMPLS tunnel LSP is signaled over the GMPLS Bitar, et al. Expires April 24, 2012 [Page 3] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 UNI and across the MPLS transport network. The LSP endpoint at R1 is presented as an IP interface to R1. The LSP endpoint at R2 is presented as an IP interface to R2. ISIS(-TE) is enabled on these IP interfaces. In addition, other IP-based protocols such as RSVP-TE, LDP, PIM-SM(SSM), etc., can be enabled on these interfaces. It should be noted that if OSPF is enabled in addition or instead of ISIS over these interfaces, OSPF packets can be carried over the GMPLS LSP tunnel using the existing MPLS encapsulation architecture [RFC 3032] for transporting IP packets. When the tunnel LSP is active at R1 and R2, ISIS adjacency formation starts and ISIS adjacency is established. Subsequent to that ISIS Link state packets are flooded over that LSP as on any other ISIS link. Other LSPs can be established over this ISIS link (the LSP tunnel) via RSVP-TE, GMPLS, LDP, etc. When R1 sends an ISIS packet to R2, it first imposes the explicit ISIS NULL label whose value TBD, with the S-bit to 1, the TC set to a configured value, and TTL set to 1, and then encapsulates the MPLS packet with the LSP tunnel header. When R1 sends R2 an IPv4 control protocol (e.g., RSVP-TE, LDP, PIM), or a user IPv4 packet, it encapsulates the IPv4 packet with the LSP tunnel header. When R1 sends R2 an IPv6 control protocol (e.g., RSVP-TE, LDP, PIM), or a user IPv6 packet, it first imposes on the packet the IPv6 Explicit NULL label (label value = 2) with the S bit set to 1, followed by a label header corresponding to the GMPLS LSP tunnel. When R1 sends an MPLS packet to R2, it encapsulates the MPLS packet with the LSP tunnel header. In this case, R1 may be a transit node for the LSP whose MPLS packet is being switched across the tunnel GMPLS LSP, or the head-end of that LSP. Upon receiving a packet over the GMPLS LSP tunnel configured as a routing adjacency, R1 performs the following processing: 1. It pops the GMPLS LSP label, preserving the context of that label as an IP interface Bitar, et al. Expires April 24, 2012 [Page 4] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 2. If the encapsulated packet is an MPLS packet, as indicated by the outer label (tunnel label) tag S-bit set to 0, R1 performs a label lookup on the top label, after popping the tunnel label. The following cases exist: a. The label matches the ISIS Explicit NULL label value: the encapsulated packet is an ISIS packet. The ISIS packet is sent to the control plane. b. The label matches the IPv6 Explicit NULL label value: the encapsulated packet is an IPv6 packet, the IPv6 Explicit Null label is popped, and the IPv6 packet is routed appropriately. c. Otherwise, the label is switched, or popped depending on the label context. 3. If the encapsulated packet is not an MPLS packet, (i.e., the tunnel label had the S bit set to 1), it is assumed that the encapsulated packet is an IPv4 packet. 3. ISIS Packet Encapsulation format Figure 2 depicts the protocol stack for an ISIS packet encapsulated over the GMPLS LSP tunnel. +-------------------------------+ Tunnel label header | tunnel-label | TC| S=0| TTL | |-------------------------------| ISIS Explicit NULL label |ISIS NULL label| TC| S=1| TTL=1| |-------------------------------| | | | | | ISIS Packet | | | | | | | | | +-------------------------------+ Figure 2: Encapsulation of an ISIS packet in a tunnel LSP treated as a routing adjacency Bitar, et al. Expires April 24, 2012 [Page 5] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 4. IANA Consideration This document requires the designation of a label value in the reserved MPLS Label space for the ISIS Explicit NULL label. 5. Security Considerations No new security issues are introduced in this document beyond what is addressed for MPLS, GMPLS and all the IP protocols. 6. References 6.1. Normative References [RFC 3032] Rosen, E., et. al, "MPLS Label Stack Encoding", RFC 3032, January, 2011. [RFC 5921] Bocci, M., et. al, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. 6.2. Informative References [RFC 4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. Authors' Addresses Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Himanshu Shah Ciena Corp Email: hshah@ciena.com Bitar, et al. Expires April 24, 2012 [Page 6] Internet-Draft ISIS MPLS Explicit NULL Label October 2011 George Swallow Cisco Email: swallow@cisco.com Bitar, et al. Expires April 24, 2012 [Page 7]