Internet DRAFT - draft-bitar-mpls-isis-explicit-null-label

draft-bitar-mpls-isis-explicit-null-label










     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]