idnits 2.17.1 draft-jamoussi-mpls-vns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 58 has weird spacing: '...etworks aroun...' == Line 219 has weird spacing: '...es that label...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-01 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2340 (ref. '3') -- No information found for draft-mpls-ldp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-01 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group B. Jamoussi 3 Internet Draft D. Jamieson 4 Expiration Date: February 1999 P. Beaubien 5 Nortel (Northern Telecom) Ltd. 6 August 1998 8 MPLS-VNS Interworking 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document specifies MPLS [1,2] to VNS [3] interworking in an 33 efficient manner that preserves the label switching property when 34 crossing an MPLS/VNS boundary. The interworking function also ensures 35 that COS characteristics of an LSP are preserved when going from VNS 36 to MPLS and vice versa. 38 Table of Contents 40 1 Introduction ............................................ 2 41 2 Interworking Through VNS ................................ 3 42 2.1 Label Distribution ...................................... 3 43 2.2 Label Stack Encoding .................................... 4 44 3 Interworking Between MPLS and VNS ....................... 5 45 3.1 Label Distribution ...................................... 5 46 3.2 Label Stack Encoding .................................... 5 47 4 Summary ................................................. 5 48 5 Security Considerations ................................. 6 49 6 Acknowledgement ......................................... 6 50 7 References .............................................. 6 51 8 Authors' Addresses ...................................... 6 53 1. Introduction 55 Nortel's Virtual Network Switching (VNS) is defined in [3]. VNS 56 offers several unique capabilities such as the transport of IP, IPX 57 and Bridging traffic in a multi-service network (voice, video, and 58 data). It has been deployed in many live networks around the globe. 60 Multi-Protocol Label Switching (MPLS) architecture and framework are 61 defined in [1] and [2] respectively. MPLS is an emerging protocol 62 being standardized by the IETF. As the development of MPLS progresses 63 and its deployment in customer networks takes place, it becomes 64 necessary to provide a solution for interworking MPLS and VNS 65 networks. 67 MPLS and VNS are two technologies that forward IP traffic based on a 68 fixed size label to avoid processing IP headers at tandem nodes 69 between the source and the destination. 71 This document specifies MPLS-VNS interworking in an efficient manner 72 that preserves the fast forwarding of packets based on labels when 73 crossing an MPLS/VNS boundary. The interworking function also ensures 74 that COS characteristics of an LSP are preserved when going from VNS 75 to MPLS and vice versa. 77 It is possible to interwork MPLS and VNS at the IP layer by 78 terminating an MPLS label switched path (LSP), mapping the IP 79 destination address to a VNS label, and forwarding packets inside the 80 VNS domain based on the VNS label. However, this solution would 81 invoke L3 forwarding at the boundary between MPLS and VNS. 83 The solution described in this draft ensures that label forwarding is 84 preserved at the interworking point between MPLS and VNS. Two 85 interworking scenarios are identified. In the first scenario, traffic 86 is exchanged between two MPLS nodes through a VNS network. For 87 example between nodes 1 and 4 shown in Figure 1. In the second 88 scenario, traffic is exchanged between an MPLS node and a VNS node 89 (e.g., between nodes 1 and 2 of Figure 3). 91 Interworking through VNS is described in Section 2. Interworking 92 between VNS and MPLS is described in section 3. Section 4 concludes 93 this draft. 95 This document should be read along with a companion document, 96 Nortel's Virtual Network Switching (VNS) Overview [3]. 98 2. Interworking through VNS 100 This section describes the interworking functions that are required 101 in order to connect two MPLS nodes through a VNS network. Section 2.1 102 specifies the label distribution protocol. Section 2.2 specifies the 103 label stack encoding. 105 LDP Sessions 106 +-------------------+ 107 | | 108 MPLS Domain | VNS Domain | MPLS Domain 109 +------+ +------+ +------+ +------+ 110 | | | | +-----+ | | | | 111 | | |M V| | | |V M| | | 112 | |---+-----|P N|--- ----|N P|---+-----| | 113 | | |L S| | | |S L| | | 114 | | |S | +-----+ | S| | | 115 | 1 | | 2 | | 3 | | 4 | 116 +------+ +------+ +------+ +------+ 118 Figure 1. MPLS--VNS Interworking 120 2.1 Label Distribution Protocol 122 In a VNS Network, three separate nodal functions are defined. An 123 ingress function, an egress function, and a tandem (or core) 124 function. The ingress and egress nodes define the boundary between an 125 MPLS domain and the VNS domain as shown in Figure 1 (nodes 2 and 3). 127 In MPLS, label to stream binding information is communicated through 128 a label distribution protocol [4] between peer Label Switching 129 Routers (LSRs). In the example of Figure 1, nodes 2 and 3 are LDP 130 peers. Therefore, in order for MPLS label information to be 131 communicated across a VNS domain, an LDP session is established 132 between all the ingress and egress VNS nodes of a logical network. 133 Tandem (or core) VNS nodes do not need to participate in LDP. 135 VNS supports a multicast forwarding service for traffic within a 136 Logical Network (LN) [3] at the VNS layer. Multicast packets are 137 delivered to all nodes supporting the logical network to which the 138 multicast packet belongs. 140 The LDP session establishment takes advantage of this VNS multicast 141 capability to send "Hello" packets. Edge nodes performing the VNS- 142 MPLS interworking function are able to dynamically discover each 143 other through VNS multicast. 145 Inside the VNS network, VNS uses it own label distribution mechanism 146 which is based on a distributed serverless topology driven approach. 147 Standard ARP is used to distribute a mapping between network layer 148 addresses and VNS labels. 150 As described in [3], a VNS Label is composed of the destination node 151 ID and the Logical Network Number (LNN). When an ingress VNS node 152 receives the ARP reply that maps an IP prefix to a VNS label, it 153 initiates an LDP session with that destination node as specified in 154 [4]. This LDP session is used to exchange MPLS label mappings to FECs 155 between the two VNS edge nodes. 157 2.2 Label Stack Encoding 159 When packets are carried in an MPLS domain, the standard label stack 160 encoding defined in [5] is used. When packets enter a VNS network, a 161 VNS label defined in [3] is pushed on top of the MPLS stack resulting 162 in a stack depth of at least two labels. The top label is the VNS 163 label. The bottom label is the MPLS shim encoding defined in [5]. 164 Packets are forwarded inside the VNS network based on the VNS header 165 as defined in [3]. When a packet is about to leave a VNS network, the 166 VNS header is popped and MPLS-based label forwarding is resumed. 167 Figure 2. shows the label stack encoding of an IP packet as it 168 traverses a VNS domain. 170 +--------------+----+-------------+------------+ 171 | Data | IP | MPLS Header | VNS Header | 172 +--------------+----+-------------+------------+ 174 Figure 2. MPLS/VNS Label Stack Encoding 176 A Protocol Type field in the VNS header indicates the type of 177 protocol being carried in the VNS packet. Examples include IP, IPX, 178 and Bridging. If the packet is a multicast packet then this is 179 indicated in this field. 181 A new codepoint is defined in this Protocol Type field to indicate 182 that the packet being carried by VNS is an MPLS packet. 184 The MPLS shim encoding includes a 3-bit COS field used to indicate 185 the Class of Service of the packet. The VNS header also includes a 186 3-bit COS field. A mapping function between the MPLS and the VNS COS 187 fields ensures that packets receive a consistent queuing and 188 scheduling treatment in both the MPLS and the VNS domains. 190 In addition, the VNS header includes a Discard Priority field that 191 indicates the level of congestion at which the packet should be 192 dropped. The MPLS shim encoding does not have a field that indicates 193 the discard eligibility of a packet. Therefore, a mapping to the MPLS 194 COS field is necessary. 196 3. Interworking between VNS and MPLS 198 This section describes the interworking functions required to 199 preserve the label switching path when traffic is terminated on an 200 MPLS node on one end and a VNS node on the other. 202 MPLS Domain VNS Domain 203 +------+ +------+ 204 | | +------+ | | 205 | | |M V| | | 206 | |-------|P N|-------| | 207 | | |L S| | | 208 | 1 | |S | | 2 | 209 +------+ +------+ +------+ 211 Figure 3. MPLS--VNS Interworking 213 3.1 Label Distribution 215 In this interworking mode, labels are distributed within the MPLS 216 domain as defined in [4] and within the VNS domain as defined in [3] 217 independently of each other. At the node of intersection of the VNS 218 and MPLS domains, the lack of an LDP session with a remote MPLS peer 219 for a given stream indicates that label swapping is to take place at 220 that node. Therefore, the forwarding table is populated accordingly. 222 3.2 Label Stack Encoding 224 Since in this mode of operation, traffic is terminating on a VNS node 225 on one end and on an MPLS node on the other, label stack encoding 226 defined in [5] is used within the MPLS domain and label encoding 227 defined in [3] is used in the VNS domain. At the point of 228 intersection, a swapping operation is performed between the VNS and 229 MPLS labels. 231 4. Summary 233 VNS uses a label switching scheme to forward IP packets in a VNS 234 domain. Many live networks are running VNS to switch their IP 235 traffic. MPLS is an emerging standard that also uses label switching 236 to carry IP traffic. As MPLS networks get deployed, it becomes 237 necessary to provide an MPLS-VNS Interworking solution. 239 This draft describes an architectural view of how MPLS and VNS 240 interworking can be done in an efficient manner that preserves the 241 label switching property at the MPLS/VNS boundary nodes. 243 Two interworking scenarios are identified. In the first scenario, 244 traffic is exchanged between two MPLS nodes through a VNS network. In 245 this case, LDP is used to carry label bindings between MPLS peer 246 nodes across a VNS domain. VNS uses its label distribution protocol 247 to map IP reachability to VNS labels. At least a two-label-stack is 248 used to carry traffic across a VNS domain. The top label is a VNS 249 label (as defined in [3]) and the bottom label is an MPLS label (as 250 defined in [5]). 252 In the second interworking scenario, traffic is exchanged between an 253 MPLS node and a VNS node. In this case, a label swapping function is 254 invoked at the VNS-MPLS boundary. 256 5. Security Considerations 258 Security issues are not discussed in this memo. 260 6. Acknowledgements 262 The authors would like to acknowledge the valuable comments of Jerry 263 Wu, Denis Fortier, Robert Eros, and Pierre Cousineau. 265 7. References 267 [1] E. Rosen et al, "Multiprotocol Label Switching Architecture", 268 draft-ietf-mpls-arch-01.txt, March 1998. 270 [2] R. Callon, et. al., "A Framework for Multiprotocol Label 271 Switching", draft-ietf-mpls-framework-02.txt, November 21, 1997. 273 [3] B. Jamoussi, et. al., "Nortel's Virtual Network Switching (VNS) 274 Overview", RFC 2340, May 1998. 276 [4] L. Anderson, et. al., "Label Distribution Protocol", draft-mpls- 277 ldp-00.txt, March 1998. 279 [5] E. Rosen, et. al., "MPLS Label Stack Encoding", draft-ietf-mpls- 280 label-encaps-01.txt, February 1998. 282 8. Authors' Addresses 284 Bilel Jamoussi 285 Nortel (Northern Telecom), Ltd. 286 PO Box 3511 Station C 287 Ottawa ON K1Y 4H7 288 Canada 290 EMail: jamoussi@nortel.com 291 Dwight Jamieson 292 Nortel (Northern Telecom), Ltd. 293 PO Box 3511 Station C 294 Ottawa ON K1Y 4H7 295 Canada 297 EMail: djamies@nortel.com 299 Paul Beaubien 300 Nortel (Northern Telecom), Ltd. 301 PO Box 3511 Station C 302 Ottawa ON K1Y 4H7 303 Canada 305 EMail: beaubien@nortel.com