idnits 2.17.1 draft-bitar-mpls-isis-explicit-null-label-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5921 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Nabil Bitar 3 Internet Draft Verizon 4 Intended status: Standards Track 5 Expires: April 24, 2012 Himanshu Shah 6 Ciena 8 George Swallow 9 Cisco 11 October 24, 2011 13 ISIS MPLS Explicit NULL Label 14 draft-bitar-mpls-isis-explicit-null-label-00.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by 28 other documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them other 30 than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be 36 accessed at http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 24,2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as 43 the document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's 46 Legal Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date 48 of publication of this document. Please review these 49 documents carefully, as they describe your rights and 50 restrictions with respect to this document. 52 Abstract 54 There is need to support IP interfaces on the top of GMPLS 55 packet Label Switched Paths (LSPs), and enable IP routing 56 (e.g., OSPF-TE, ISIS-TE) and MPLS protocols on these 57 interfaces. Traffic on an IP/MPLS interface can be user 58 traffic or control traffic. In addition, it can be MPLS, IP 59 or ISIS. Multiplexing IP and MPLS packets over the same LSP 60 is supported in the current MPLS architecture. However, 61 multiplexing IP, MPLS, and ISIS packets over the same LSP is 62 not currently supported. This draft proposes the definition 63 of an explicit ISIS NULL label to enable this type of 64 multiplexing to take place. 66 Table of Contents 68 1. Introduction..............................................2 69 2. Operational Procedures....................................3 70 3. ISIS Packet Encapsulation format..........................5 71 4. IANA Consideration........................................6 72 5. Security Considerations...................................6 73 6. References................................................6 74 6.1. Normative References.................................6 75 6.2. Informative References...............................6 77 1. Introduction 79 RFC 4206 [RFC 4206] defines the concept of a forwarding 80 adjacency (FA) built on a Traffic Engineered (TE) LSP. An FA 81 can be unidirectional and signaled via RSVP-TE, or 82 bidirectional and signaled via RSVP-TE with GMPLS 83 extensions. It is signaled over the same network on which 84 it is routed. An FA is included in the network IGP link 85 state database as a TE link but used only for forwarding. 86 That is, it is never used to establish a routing adjacency. 87 Routing adjacencies are necessary in a link-state IGP 88 network for topology discovery and link-state information 89 dissemination. FAs capitalize on the existence of routing 90 adjacencies, and routers make use of the topology 91 information exchanged over these adjacencies to establish 92 the FAs. 94 In MPLS-TP, client network islands that belong to the same 95 IGP are interconnected over an MPLS-TP [RFC 5921] server 96 network in an overlay model. A client network island is 97 connected to the MPLS-TP network via a border client router. 98 Two client border-routers need to form a routing adjacency 99 over a GMPLS LSP signaled through the MPLS-TP network via 100 GMPLS UNI signaling. The GMPLS UNI is the interface between 101 the client border node and the connected MPLS-TP network 102 edge. 104 This document introduces the explicit ISIS NULL label that 105 enables the establishment of an ISIS(-TE) routing 106 adjacency over a GMPLS LSP, and to treat that routing 107 adjacency as any IP adjacency, enabling MPLS signaling, IP and 108 MPLS multicast signaling/routing, and MPLS and IP forwarding 109 over that adjacency. 111 2. Operational Procedures 113 <-------- ISIS, RSVP-TE, LDP, PIM, LDP, BFD ------> 115 <---------- Tunnel LSP: Routing Adjacency --------> 117 <---Transport LSP---> 119 GMPLS UNI GMPLS UNI 120 +-+--+ +----+ +----+ +----+ 121 | R1 |+-------+| PE1|+-----------------+|PE2 |+-----+| R2 | 122 +----+ +----+ +----+ +----+ 124 Figure 1: Reference Model for GMPLS LSP Tunnel as an IP 125 interface 127 Figure 1 depicts a reference model for the GMPLS UNI and 128 GMPLS LSP routing adjacency, referred to as tunnel LSP. R1 129 connects to the MPLS transport network via a GMPLS UNI 130 interface between R1 and PE1. R2 connects to the MPLS 131 transport network via a GMPLS UNI interface between R2 and 132 PE2. A GMPLS tunnel LSP is signaled over the GMPLS 133 UNI and across the MPLS transport network. The LSP endpoint at 134 R1 is presented as an IP interface to R1. The LSP endpoint at 135 R2 is presented as an IP interface to R2. ISIS(-TE) is 136 enabled on these IP interfaces. In addition, other IP-based 137 protocols such as RSVP-TE, LDP, PIM-SM(SSM), etc., can be 138 enabled on these interfaces. It should be noted that if OSPF 139 is enabled in addition or instead of ISIS over these 140 interfaces, OSPF packets can be carried over the GMPLS LSP 141 tunnel using the existing MPLS encapsulation architecture 142 [RFC 3032] for transporting IP packets. 144 When the tunnel LSP is active at R1 and R2, ISIS adjacency 145 formation starts and ISIS adjacency is established. Subsequent 146 to that ISIS Link state packets are flooded over that LSP as 147 on any other ISIS link. Other LSPs can be established over 148 this ISIS link (the LSP tunnel) via RSVP-TE, GMPLS, LDP, etc. 150 When R1 sends an ISIS packet to R2, it first imposes the 151 explicit ISIS NULL label whose value TBD, with the S-bit to 1, 152 the TC set to a configured value, and TTL set to 1, and then 153 encapsulates the MPLS packet with the LSP tunnel header. 155 When R1 sends R2 an IPv4 control protocol (e.g., RSVP-TE, 156 LDP, PIM), or a user IPv4 packet, it encapsulates the IPv4 157 packet with the LSP tunnel header. 159 When R1 sends R2 an IPv6 control protocol (e.g., RSVP-TE, 160 LDP, PIM), or a user IPv6 packet, it first imposes on the 161 packet the IPv6 Explicit NULL label (label value = 2) with 162 the S bit set to 1, followed by a label header corresponding 163 to the GMPLS LSP tunnel. 165 When R1 sends an MPLS packet to R2, it encapsulates the MPLS 166 packet with the LSP tunnel header. In this case, R1 may be a 167 transit node for the LSP whose MPLS packet is being switched 168 across the tunnel GMPLS LSP, or the head-end of that LSP. 170 Upon receiving a packet over the GMPLS LSP tunnel configured 171 as a routing adjacency, R1 performs the following 172 processing: 174 1. It pops the GMPLS LSP label, preserving the context of 175 that label as an IP interface 177 2. If the encapsulated packet is an MPLS packet, as 178 indicated by the outer label (tunnel label) tag S-bit 179 set to 0, R1 performs a label lookup on the top label, 180 after popping the tunnel label. The following cases 181 exist: 183 a. The label matches the ISIS Explicit NULL label 184 value: the encapsulated packet is an ISIS packet. 185 The ISIS packet is sent to the control plane. 187 b. The label matches the IPv6 Explicit NULL label 188 value: the encapsulated packet is an IPv6 packet, 189 the IPv6 Explicit Null label is popped, and the 190 IPv6 packet is routed appropriately. 192 c. Otherwise, the label is switched, or popped 193 depending on the label context. 195 3. If the encapsulated packet is not an MPLS packet, 196 (i.e., the tunnel label had the S bit set to 1), it is 197 assumed that the encapsulated packet is an IPv4 packet. 199 3. ISIS Packet Encapsulation format 201 Figure 2 depicts the protocol stack for an ISIS packet 202 encapsulated over the GMPLS LSP tunnel. 204 +-------------------------------+ 205 Tunnel label header | tunnel-label | TC| S=0| TTL | 206 |-------------------------------| 207 ISIS Explicit NULL label |ISIS NULL label| TC| S=1| TTL=1| 208 |-------------------------------| 209 | | 210 | | 211 | ISIS Packet | 212 | | 213 | | 214 | | 215 | | 216 +-------------------------------+ 218 Figure 2: Encapsulation of an ISIS packet in a tunnel LSP 219 treated as a routing adjacency 221 4. IANA Consideration 223 This document requires the designation of a label value in 224 the reserved MPLS Label space for the ISIS Explicit NULL 225 label. 227 5. Security Considerations 229 No new security issues are introduced in this document 230 beyond what is addressed for MPLS, GMPLS and all the IP 231 protocols. 233 6. References 235 6.1. Normative References 237 [RFC 3032] Rosen, E., et. al, "MPLS Label Stack Encoding", 238 RFC 3032, January, 2011. 240 [RFC 5921] Bocci, M., et. al, "A Framework for MPLS in 241 Transport Networks", RFC 5921, July 2010. 243 6.2. Informative References 245 [RFC 4206] Kompella, K., and Rekhter, Y., "Label Switched 246 Paths (LSP) Hierarchy with Generalized Multi-Protocol Label 247 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 248 October 2005. 250 Authors' Addresses 252 Nabil Bitar 253 Verizon 254 40 Sylvan Road 255 Waltham, MA 02145 256 Email: nabil.bitar@verizon.com 258 Himanshu Shah 259 Ciena Corp 260 Email: hshah@ciena.com 261 George Swallow 262 Cisco 263 Email: swallow@cisco.com