idnits 2.17.1 draft-sumimoto-mpls-vpn-interworking-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 8, 2000) is 8837 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) == Unused Reference: 'RFC1483' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'VLAN' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'MPLSVPN' is defined on line 363, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1483 (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. 'VLAN' ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'GMN-CL' == Outdated reference: A later version (-03) exists of draft-muthukrishnan-mpls-corevpn-arch-00 ** Downref: Normative reference to an Informational draft: draft-muthukrishnan-mpls-corevpn-arch (ref. 'COREVPNARCH') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Normative reference to a draft: ref. 'MPLSVPN' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Junichi Sumimoto 3 INTERNET-DRAFT Muneyoshi Suzuki 4 Expires August 8, 2000 NTT 6 Osamu Tabata 7 Atsushi Iwata 8 NEC Corporation 10 Yutaka Ezaki 11 Masami Doukai 12 Fujitsu Limited 14 February 8, 2000 16 MPLS VPN Interworking 18 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 We call virtual private networks (VPNs) based on Multiprotocol Label 44 Switching (MPLS) "MPLS VPN". This document discusses motivation and 45 a model of interworking among MPLS VPNs. It then proposes functional 46 capabilities for the interworking such as realization of security, 47 mapping of the QoS class, dynamic routing information distribution. 49 Considering easy provisioning, we focus on an interworking where each 50 MPLS network is once terminated and IP header look-up is executed at 51 an egress/ingress Label Switching Router (LSR), and IP over ATM 52 (RFC1483) is used for interworking connections. 54 1. Introduction 56 MPLS enables the forwarding of IP packets under the control of a 57 standard IP routing algorithm, but the forwarding process does not 58 use the IP packet header directly. Instead, a short, fixed-length 59 label is used to enable packet forwarding. We call VPNs based on 60 MPLS "MPLS VPN". A number of MPLS VPN solutions (including pre- 61 standard solutions) have been proposed and developed, where the 62 interface between a user and a provider is IP. These include BGP/VPN 63 [RFC2547], GMN-CL [GMN-CL] and [COREVPNARCH]. But there is no 64 agreement for interworking among MPLS VPNs. VPN architecture based 65 on MPLS is already under discussion in ITU-T SG13 [I.IPATM]. 67 We therefore discuss the following: 68 - Motivation for interworking among VPNs (Section 2) 69 - Assumptions of MPLS VPNs as elements for interworking 70 (Section 3) 71 - Functional capabilities for interworking such 72 as realization of security, mapping of the QoS class, 73 dynamic routing information distribution (Section 4) 75 2. Motivation for interworking among MPLS VPNs 77 (1) VPNs spread over multiple differently implemented MPLS networks 78 owned by different VPN service providers. This follows the normal 79 requirement and expectation that each VPN service provider chooses 80 its best VPN implementation out of multiple vendors' implementations. 82 (2) VPNs spread over multiple differently implemented MPLS networks 83 owned by a VPN service provider. A VPN service provider may deploy 84 multiple MPLS networks (e.g., an old MPLS network and a new MPLS 85 network). The VPN interworking removes the requirement that the all 86 user sites of one VPN need to be connected to an MPLS network. 88 In both cases, the interworking enable VPN service providers to make 89 flexible provisioning of VPN services. It is of benefit to VPN users 90 as well. 92 3. Assumptions 94 3.1 MPLS Network 96 The following MPLS network structure [MPLSARC] is assumed to be 97 present as a base to provide VPN services. 99 +--------------------+ 100 | | 101 +-----+ Backbone Network +-----+ 102 User sites -+--| LSR | implementing MPLS | LSR |--+- User sites 103 +-----+ +-----+ 104 | | 105 +--------------------+ 107 Figure 1. Structure of MPLS Network 109 3.2 MPLS VPN 111 3.2.1 Security support 113 Each user-side logical/physical port of an ingress/egress LSR belongs 114 to only one VPN. Traffic between any pair of such ports that belong 115 to a VPN is isolated from traffic of any other VPNs, so a host of a 116 user site belonging to any other VPNs is not permitted to send any 117 packets to the VPN. 119 For example, the following mechanisms realize the traffic isolation 120 in an MPLS backbone network. 122 - At each egress/ingress LSR, each VPN is managed by a number, 123 label, or identifier. In some implementations, each VPN is 124 identified by an label (LSP), while in the other 125 implementations, each VPN is identified by an number or 126 identifier [VPNID] that is explicitly attached to packets in 127 the MPLS network. 129 3.2.2 QoS class support 131 The MPLS VPN supports QoS classes, for example, Assured Forwarding 132 (AF) Classes of diffserv [RFC2475]. 133 A QoS class of each packet is identified by attributes concerning the 134 logical/physical interface of the egress/ingress LSR, source and/or 135 destination IP address, port number, diffserv codepoint, and so on. 136 The backbone network between an ingress LSR and an egress LSR 137 controls QoS based packet forwarding. 139 3.2.3 Dynamic routing information distribution 141 An MPLS network can dynamically distribute the routing information of 142 each VPN (1)within the MPLS network and (2)between the MPLS network 143 and a user site. Scope of the distribution is restricted within each 144 VPN by the security support (See section 3.2.1). 146 4. Proposed Model, Functional Capabilities for Interworking among MPLS 147 VPNs 149 4.1 Interworking Model 151 +---------+ +---------+ 152 VPN A | | | | VPN A 153 +----------------------------------------------------------------------+ 154 | +---+ +---+ +---+ +---+ | 155 |User site | | Element | | | | Element | | User site| 156 | of VPN A-| | W | | | | X | |- of VPN A| 157 | | | | | | | | | | 158 +----------------------------------------------------------------------+ 159 | | | |Interworking| | | | 160 |LSR| |LSR|-----++-----|LSR| |LSR| 161 | | | | Interface | | | | 162 +----------------------------------------------------------------------+ 163 | | | | | | | | | | 164 |User site-| | Element | | | | Element | |-User site| 165 | of VPN B | | Y | | | | Z | | of VPN B| 166 | +---+ +---+ +---+ +---+ | 167 +----------------------------------------------------------------------+ 168 VPN B | | | | VPN B 169 +---------+ +---------+ 170 MPLS Network 1 MPLS Network 2 172 Figure 2. Interworking Model 174 We call each part of a VPN that is cut by an MPLS network 'element'. 176 4.2 Functional Capabilities for Interworking 178 There are the following two types of interworking. 180 (1)Interworking where each MPLS network is once terminated 181 and IP header look-up is executed at an egress/ingress LSR. 183 (2)Interworking without IP header look-up at an egress/ingress 184 LSR. 186 As each existing MPLS VPN is implemented in unique manner, it is 187 difficult to realize type (2). Type (1) is easy to provision since it 188 utilize the LSR's function of IP header look-up. Therefore, we focus on 189 type (1). 191 We assume that the connections at the interworking interface are 192 provided by IP over ATM (RFC1483) since IP over ATM has advantage for 193 bandwidth control per logical connection. Use of other layer 2 protocol 194 other than ATM and use of MPLS shim header is for further study. These 195 connections are assumed to convey routing protocol packets as well as 196 data packets of each VPN. No assumptions about which flavor of VPNs is 197 run on the other side is required. 199 We propose the following three functional capabilities, which are 200 required to support MPLS VPN interworking. 202 - Realization of security 203 - Mapping of the QoS class 204 - Dynamic routing information distribution 206 in section 4.3, section 4.4, section 4.5, respectively. 208 4.3 Realization of Security 210 Each end of each connection is assigned an MPLS VPN of MPLS network that 211 is connected to the end of the connection. Any packets are not 212 permitted to transmit between the connection and any unassigned MPLS 213 VPNs. This mechanism result in realization of security. The procedures 214 by which such an assignment is established are specific to the solution 215 used by the MPLS network implementation associated with the connection. 216 The identity of VPN at each end is meaningful only in the context of the 217 specific MPLS network associated with the connection. We assume 218 multiple VPNs do not share one connection. 220 See figure 2. There used a logical connection between the MPLS network 221 1 and MPLS network 2 for constructing a VPN over both MPLS network 1 and 222 MPLS network 2. The connection for the VPN A is assigned to element 'W' 223 and 'W' is meaningful only in the context of MPLS network 1. The other 224 side of the connection is assigned to element 'X' and 'X' is meaningful 225 only in the context of MPLS network 2. 227 Note. We recommend that bandwidth of a connection does not interfere 228 with bandwidth of any other connections. Detailed QoS specifications of 229 the connection are for further study. 231 4.4 Mapping of the QoS class 233 Attributes of a QoS class may be also assigned to each connection. This 234 enables provisioning of multiple QoS classes within each VPN. QoS 235 control is easy and only one-time class identification in the IP layer 236 is needed. 238 +-----------+ +-----------+ 239 +-----+ +-----+ +-----+ +-----+ 240 | +-----------+ | | +-----------+ | 241 | | Element | |-------------| | Element | | 242 | LSR | | LSR |-------------| LSR | | LSR | 243 | | W | |-------------| | X | | 244 | +-----------+ | Connections | +-----------+ | 245 +-----+ +-----+ for +-----+ +-----+ 246 +-----------+ different +-----------+ 247 MPLS network 1 QoS Classes MPLS network 2 249 Figure 3. Using multiple connections for multiple QoS classes 250 for each VPN 252 There is another optional method. 253 We can use CoS, a bit-pattern in a field such as EXP of Shim header 254 or TOS of an IP header, to identify a QoS class during packet 255 transmission on the connection. The connection is shared by 256 multiple QoS classes. A typical example of this mapping method is 257 diffserv. This method can reduce the number of connections, while 258 QoS control on the connection is difficult. 260 +-----------+ +-----------+ 261 +-----+ +-----+ +-----+ +-----+ 262 | +-----------+ | | +-----------+ | 263 | | Element | | | | Element | | 264 | LSR | | LSR |-------------| LSR | | LSR | 265 | | W | | | | X | | 266 | +-----------+ | Connection | +-----------+ | 267 +-----+ +-----+ supporting +-----+ +-----+ 268 +-----------+ CoS +-----------+ 269 MPLS network 1 MPLS network 2 271 Figure 4. Using CoS for supporting multiple QoS classes for each VPN 273 4.5 Dynamic routing information distribution 275 Some mechanisms for routing control per VPN are required in each 276 egress/ingress LSR. The connection between MPLS network 1 and MPLS 277 network 2 just transmit packets of standard IP routing. Then 278 routing information is forwarded by the functional capability 279 described in chapter 4.3 as well as data. This enables dynamic 280 routing information distribution within each VPN. One of standard 281 routing protocols such as BGP, OSPF, RIP, DVMRP, PIM can be used on 282 the connections for every VPN. 284 4.6 Summary 285 Figure 5 summarize functional capabilities for MPLS VPN 286 interworking with IP over ATM. Note that this document does not 287 require any new protocols or new label modification of existing 288 protocols. 290 +------------+ +------------+ 291 VPN A | | | | VPN A 292 +----------------------------------------------------------------------+ 293 | +---| |---+ VC for +---| |---+ | 294 | | | Data & | | QoS class 1 | | Data & | | | 295 | | | routing |---|------++------|---| routing | | | 296 |User--|---|<- inform ->| | | |<- inform ->|---|--User| 297 |site | | -ation |---|------++------|---| -ation | | site| 298 | | | | | VC for | | | | | 299 | | | Element W | | QoS class 2 | | Element X | | | 300 +----------------------------------------------------------------------+ 301 | | /| | | /| | | /| | | 302 | | | | | | | | | | | 303 |LSR| Prohibited |LSR| Prohibited |LSR| Prohibitd |LSR| 304 | | to Transmit| | to Transmit | | to Transmit| | 305 | | | | | | | | | | | 306 | | |/ | | |/ | | |/ | | 307 +----------------------------------------------------------------------+ 308 | | | | | VC for | | | | | 309 | | | Data & | | QoS class 1 | | Data & | | | 310 | | | routing |---|------++------|---| routing | | | 311 |User--|---|<- inform ->| | | |<- inform ->|---|--User| 312 |site | | -ation |---|------++------|---| -ation | | site| 313 | | | | | VC for | | | | | 314 | +---| Element Y |---+ QoS class 2 +---| Element-Z |---+ | 315 +----------------------------------------------------------------------+ 316 VPN B | | || | | VPN B 317 +------------+ Interworking +------------+ 318 MPLS Network 1 Interface MPLS Network 2 320 Figure 5. Proposed VPN Interworking by using IP over ATM 322 This document focuses on static interworking (i.e. user-plane 323 interworking) to deploy quickly. Dynamic interworking (i.e. control- 324 plane or management-plane interworking) should be discussed in another 325 document to reduce manual configuration in near future. 327 5. Acronyms 328 CoS Class of Service 329 ISP Internet Service Provider 330 LSP Label Switched Path 331 LSR Label Switching Router 332 MPLS Multiprotocol Label Switching 333 OPS Operation System 334 QoS Quality of Service 335 VPN Virtual Private Network 337 6. References 339 [RFC1483] Heinanen J., "Multiprotocol Encapsulation over ATM Adaptation 340 Layer 5," RFC1483. 342 [VLAN] IEEE 8.2.1Q. 344 [RFC2547] Rosen E. and Rekhter Y., "BGP/MPLS VPNs," RFC2547. 346 [GMN-CL] GMN-CL home page: http://www.gmncl.ecl.ntt.co.jp/top_e.html 348 [COREVPNARCH] Muthukrishnan K., et al, "Core MPLS IP VPN Architecture", 349 draft-muthukrishnan-mpls-corevpn-arch-00.txt. 351 [I.IPATM] ITU-T, "Transport of IP over ATM in Public Networks," Draft 352 recommendation, I.ipatm, September, 1999. 354 [MPLSARC] Rosen E., et al, "Multiprotocol Label Switching 355 Architecture," draft-ietf-mpls-arch-06.txt. 357 [VPNID] Fox B., et al, "Virtual Private Networks Identifier," 358 RFC2685. 360 [RFC2475] Blake S., et al, "An architecture for Differentiated 361 Services," RFC2475. 363 [MPLSVPN] Jamieson D., et al, "MPLS VPN Architecture," 364 draft-jamieson-mpls-vpn-00.txt. 366 7. Authors' address 368 Junichi Sumimoto 369 NTT (Nippon Telegraph and Telephone Corporation) 370 Information Sharing Platform Laboratories 371 9-11, Midori-Cho 3-Chome 372 Musashino-Shi, Tokyo 180-8585 Japan 374 Email: sumimoto.junichi@lab.ntt.co.jp 376 Muneyoshi Suzuki 377 NTT (Nippon Telegraph and Telephone Corporation) 378 Information Sharing Platform Laboratories 379 9-11, Midori-Cho 3-Chome 380 Musashino-Shi, Tokyo 180-8585 Japan 382 Email: suzuki.muneyoshi@lab.ntt.co.jp 384 Osamu Tabata 385 NEC Corporation 386 1753 Shimonumabe, Nakahara-ku, 387 Kawasaki-shi, Kanagawa 211-8666 389 Email:tabata@trd.tmg.nec.co.jp 391 Atsushi Iwata 392 NEC Corporation 393 C&C Media Research Laboratories 394 4-1-1 Miyazaki Miyamae-ku, Kawasaki 395 Kanagawa, 216-8555 Japan 397 E-mail: iwata@ccm.CL.nec.co.jp 399 Yutaka Ezaki 400 IP Network Systems Lab., Fujitsu Limited 401 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 402 211-8588, Japan 404 E-mail: ezaki@flab.fujitsu.co.jp 406 Masami Doukai 407 Switching Node Systems Div., Network Systems Group, Fujitsu Limited 408 2-12-5 Shimokodanaka, Nakahara-ku, Kawasaki 409 211-0041, Japan 411 E-mail: doukai@ss.ts.fujitsu.co.jp