idnits 2.17.1 draft-ietf-l1vpn-basic-mode-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 881. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-STITCHING' -- Possible downref: Non-RFC (?) normative reference: ref. 'L1VPN-FRAMEWORK' -- Possible downref: Non-RFC (?) normative reference: ref. 'L1VPN-APPLIC' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group D. Fedyk(ed.) 2 Internet Draft Nortel 3 Date Created: February 13, 2008 Y Rekhter(ed.) 4 Expiration Date: August 13, 2008 Juniper Networks 5 Intended Status: Standards Track D. Papadimitriou 6 Alcatel-Lucent 7 R. Rabbat 8 Google 9 L. Berger 10 LabN 12 Layer 1 VPN Basic Mode 13 draft-ietf-l1vpn-basic-mode-03.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other 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 accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This draft describes the Basic Mode of Layer 1 VPNs (L1VPN BM). 45 L1VPN Basic mode is a port-based VPN. In L1VPN Basic Mode (BM), the 46 basic unit of service is a Label Switched Path (LSP) between a pair 47 of customer ports within a given VPN port-topology. This document 48 defines the operational model using either provisioning or a VPN 49 auto-discovery mechanism and the signaling extensions for the L1VPN 50 BM. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 This document expects that the reader is familiar with the 59 terminology defined and used in [RFC3945], [RFC3471], [RFC3473], 60 [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208] and referenced 61 therein. 63 Table of Contents 65 1. Introduction...............................................4 66 2. Layer 1 VPN Service........................................5 67 3. Addressing, Ports, Links and Control Channels..............7 68 3.1 Service Provider Realm....................................7 69 3.2 Layer 1 Ports and Index...................................7 70 3.3 Port and Index Mapping....................................8 71 4. Port Based L1VPN Basic Mode...............................10 72 4.1 L1VPN Port Information Tables............................11 73 4.1.1. Local Auto-Discovery Information......................12 74 4.1.2. PE Remote Auto-Discovery Information..................12 75 4.2 CE to CE LSP Establishment...............................13 76 4.3 Signaling................................................14 77 4.3.1 Signaling Procedures...................................15 78 4.3.1.1 Shuffling Sessions...................................16 79 4.3.1.2 Stitched or Nested Sessions..........................16 80 4.3.1.3 Other Signaling......................................17 81 4.4 Recovery Procedures......................................18 82 5. Security Considerations...................................18 83 6. IANA Considerations.......................................19 84 7. Intellectual Property Considerations......................19 85 8. References................................................20 86 8.1 Normative References.....................................20 87 8.2 Informative References...................................20 88 9. Author's Addresses........................................21 89 10. Disclaimer of Validity...................................22 90 11. Copyright Statement......................................22 92 1. Introduction 94 This document describes the basic mode of Layer 1 VPNs (L1VPN BM) 95 that is outlined in [L1VPN-FRAMEWORK]. The applicability of Layer 1 96 VPNS is covered in [L1VPN-APPLIC]. In this document, we consider a 97 layer 1 service provider network that consists of devices that 98 support GMPLS (e.g., Lambda Switch Capable devices, Optical Cross 99 Connects, SONET/SDH Cross Connects, etc.). We partition these 100 devices into P (provider) and PE (provider edge) devices. In the 101 context of this document we will refer to the former devices as just 102 "P", and to the latter devices as just "PE". The Ps are connected 103 only to the devices within the provider's network. The PEs are 104 connected to the other devices within the network (either Ps or 105 PEs), as well as to the devices outside of the service provider 106 network. We'll refer to such other devices as Client Edge (CE) 107 devices. An example of a CE would be a GMPLS-enabled device that is 108 either a router, an SDH cross-connect, or an Ethernet switch. 110 [RFC4208] defines signaling from the CE to the PE. In the [RFC4208], 111 the terms Core Node (CN) corresponds to P and PE Nodes, edge Core 112 Node corresponds to PE, and Edge Node (EN) corresponds to CE. 114 Figure 1 illustrates the components in an L1VPN network. 116 +---+ +---+ 117 | P |....| P | 118 +---+ +---+ 119 / \ 120 +-----+ +-----+ +--+ 121 +--+ | PE | | |----| | 122 |CE|----| | | | |CE| 123 +--+\ +-----+ | |----| | 124 \ | | PE | +--+ 125 \ +-----+ | | 126 \| PE | | | +--+ 127 | | | |----|CE| 128 +-----+ +-----+ +--+ 129 \ / 130 +---+ +---+ 131 | P |....| P | 132 +---+ +---+ 134 Figure 1: Generalized Layer 1 VPN Reference Model 136 This document specifies how the L1VPN Basic Mode (BM) service can be 137 realized using off-line provisioning or VPN auto-discovery, 138 Generalized Multi-Protocol Label Switching (GMPLS) Signaling 139 [RFC3471], [RFC3473], Routing [RFC4202] and LMP [RFC4204] 140 mechanisms. 142 The L1VPN auto-discovery has similar requirements [L1VPN-FRAMEWORK] 143 to the L3VPN auto-discovery. As with L3VPNs there are protocol 144 options to be made with auto-discovery. Section 4.1.1 deals with the 145 information that needs to be discovered. 147 GMPLS routing and signaling are used without extensions within the 148 service provider network to establish and maintain Lambda Switch 149 Capable (LSC) or SONET/SDH (TDM) connections between service 150 provider nodes. This follows the model in [RFC4208]. 152 In L1VPN Basic Mode (BM), the use of LMP facilitates the population 153 of the service provider port information tables. Indeed, LMP MAY be 154 used as an option to automate local CE-PE link discovery. LMP also 155 MAY augment routing in extended mode as well as failure handling 156 capabilities. 158 2. Layer 1 VPN Service 160 Layer 1 VPN (L1VPN) services on the interfaces of customer and 161 service provider ports MAY be any of the Layer 1 interfaces 162 supported by GMPLS. Since the mechanisms specified in this document 163 use GMPLS as the signaling mechanism, and since GMPLS applies to 164 both SONET/SDH (TDM) and Lambda Switch Capable (LSC) interfaces, it 165 results that L1VPN services include (but are not restricted) to 166 Lambda Switch Capable or TDM-based equipment. Note that this 167 document describes Basic Mode L1VPNs and as such requires that: 168 (1) GMPLS RSVP-TE is used for signaling both within the service 169 provider (between PEs), as well as between the customer and the 170 service provider (between CE and PE); 171 (2) GMPLS Routing on the CE-PE link is outside the scope of the 172 basic mode of operation of L1VPN see [L1VPN-FRAMEWORK]. 174 A CE is connected to a PE via one or more links. In the context of 175 this document a link is a GMPLS Traffic Engineering (TE) link 176 construct, as defined in [RFC4202]. In the context of this document, 177 a TE link is a logical construct that is a member of a VPN hence 178 introducing the notion of membership to a set of CEs forming the 179 VPN. Interfaces at the end of each link are limited to type LSC or 180 TDM that are supported by GMPLS. More specifically a link 181 MUST be of the type or where X = PSC, L2SC or TDM 182 and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X 183 MAY also = LSC and Y = TDM. One of the applications of a L1VPN 184 connection is to provide a "virtual private lambda" or similar. In 185 this case, the CE is truly the end point in GMPLS terms and its 186 switching capability on the TE link is not relevant (although its 187 GPID MUST be signaled and identical at both CEs i.e. head-end and 188 tail-end CE). ) 190 Likewise, PEs could be any Layer 1 devices that are supported by 191 GMPLS (e.g., optical cross connects, SDH cross-connects), while CEs 192 MAY be devices at layers 1, 2 and 3 such as an SDH cross-connect, an 193 Ethernet switch, and a router respectively). 195 Each TE link MAY consist of one or more channels or sub-channels 196 (e.g., wavelength or wavelength and timeslot respectively). For the 197 purpose of this discussion all the channels within a given link MUST 198 have similar shared characteristics (e.g., switching capability, 199 encoding, type, etc.), and MAY be selected independently from the 200 CE's point of view. Channels on different links of a CE need not 201 have the same characteristics. 203 There MAY be more than one TE link between a given CE-PE pair. A CE 204 MAY be connected to more than one PE (with at least one port per 205 PE). And, conversely, a PE MAY have more than one CE from different 206 VPNs connected to it. 208 If a CE is connected to a PE via multiple TE links and all the links 209 belong to the same VPN, these links (referred to as component links) 210 MAY be treated as a single TE link using the link bundling 211 constructs [RFC4201]. 213 In order to satisfy the requirements of the L1VPN Basic Mode it is 214 REQUIRED that for a given CE-PE pair at least one of the links 215 between them has at least one data bearing channel, and at least one 216 control bearing channel, or there is IP reachability between the CE 217 and the PE that could be used to exchange control information. 219 A point-to-point link has two end-points - one on the CE and one on 220 the PE. This document refers to the former as "CE port", and to the 221 latter as "PE port". From the above it follows that a CE is 222 connected to a PE via one or more ports, where each port MAY consist 223 of one or more channels or sub-channels (e.g., wavelength or 224 wavelength and timeslot respectively), and all the channels within a 225 given port have shared similar characteristics and can be 226 interchanged from the CE's point of view. Similar to the definition 227 of a TE link, in the context of this document, ports are logical 228 constructs that are used to represent a grouping of physical 229 resources that are used to connect a CE to a PE on a per L1VPN 230 basis. 232 At any point in time, a given port on a PE is associated with at 233 most one L1VPN, or to be more precise with at most one Port 234 Information Table maintained by the PE (although different ports on 235 a given PE could be associated with different L1VPNs, or to be more 236 precise with different Port Information Tables). The association of 237 a port with a VPN MAY be defined by provisioning the relationship on 238 the service provider devices. In other words the context of a VPN 239 membership in Basic mode is enforced through service provider 240 control. 242 It is REQUIRED that the interface between the CE and PE used for the 243 purpose of signaling be capable of initiating/processing GMPLS 244 protocol messages [RFC3473] and follow the procedures described in 245 [RFC4208]. 247 An important goal of L1VPN service is the ability to support what is 248 known as "single-ended provisioning", where the addition of a new 249 port to a given L1VPN involves configuration changes only on the PE 250 that has this port. The extension of this model to the CE is 251 outside the scope of the L1VPN BM. 253 Another important goal in the L1VPN service is the ability to 254 establish/terminate an LSP between a pair of (existing) ports within 255 an L1VPN from the CE devices without involving configuration changes 256 in any of the service provider's devices. In other words, the VPN 257 topology is under the CE device control (provided that the 258 underlying PE-PE connectivity be provided and allowed by the 259 network). 261 The mechanisms outlined in this document aim to achieve these above 262 goals. Specifically, as part of the L1VPN service offering, these 263 mechanisms (1) enable the service provider to restrict the set of 264 ports to which a given port could be connected, (2) enable a CE to 265 establish the actual LSP to a subset of ports. Finally, the 266 mechanisms allow arbitrary L1VPN topologies to be supported ranging 267 from hub-and-spoke to full mesh point-to-point connections. Only 268 point-to-point links are supported. 270 The exchange of CE routing or topology information to the service 271 provider is out of scope for L1VPN BM mode. 273 3. Addressing, Ports, Links and Control Channels 275 GMPLS-established conventions for addressing and link numbering are 276 discussed in [RFC3945]. This section builds on those definitions 277 for the L1VPN case where we now have customer and service provider 278 addresses in a Layer 1 context. 280 3.1 Service Provider Realm 282 It is REQUIRED that a service provider, or a group of service 283 providers that collectively offer L1VPN service, have a single 284 addressing realm that spans all PE devices involved in providing the 285 L1VPN service. This is necessary to enable GMPLS mechanisms for path 286 establishment and maintenance. We will refer to this realm as the 287 service provider addressing realm. Is is further REQUIRED that each 288 L1VPN customer have its own addressing realm. We will refer to such 289 realms as the customer addressing realms. Customer addressing realms 290 MAY overlap addresses (i.e. non unique address) with each other, and 291 MAY also overlap addresses with the service provider realm. 293 3.2 Layer 1 Ports and Index 294 Within a given L1VPN, each port on a CE that connects the CE to a PE 295 has an identifier that is unique within that L1VPN (but need not be 296 unique across several L1VPNs). One way to construct such an 297 identifier is to assign each port an address that is unique within a 298 given L1VPN, and use this address as a port identifier. Another way 299 to construct such an identifier is to assign each port on a CE an 300 index that is unique within that CE, assign each CE an address that 301 is unique within a given L1VPN, and then use a tuple as a port identifier. Note that both the port and the CE 303 address MAY be an address in several formats. This includes, but is 304 not limited to IPv4, and IPv6. This identifier is part of the 305 Customer addressing Realm and is used by the CE device to identify 306 the CE port and the CE remote port for signaling. CEs do not know 307 or understand the service provider Realm addresses. 309 Within a service provider network, each port on a PE that connects 310 that PE to a CE has an identifier that is unique within that 311 network. One way to construct such an identifier is to assign each 312 port on a PE an index that is unique within that PE, assign each PE 313 an IP address that is unique within the service provider addressing 314 realm, and then use a tuple or as a port identifier within the service 316 provider network. Another way to construct such an identifier is to 317 assign an IPv4 or IPv6 address that is unique within the service 318 provider addressing realm to each such port. Either way, this IPv4 319 or IPv6 address is internal to the service provider network and is 320 used for GMPLS signaling within the service provider network. 322 As a result, each link connecting the CE to the PE is associated 323 with a CE port that has a unique identifier within a given L1VPN, 324 and with a PE port that has a unique identifier within the service 325 provider network. We'll refer to the former as the customer Port 326 Identifier (CPI), and to the latter as the Provider Port Identifier 327 (PPI). 329 3.3 Port and Index Mapping 331 This document requires that each PE port that has a PPI also has an 332 identifier that is unique within the L1VPN customer addressing realm 333 of the L1VPN associated with that port. One way to construct such 334 an identifier is to assign each port an address that is unique 335 within a given L1VPN customer addressing realm, and use this address 336 as a port identifier. Another way to construct such an identifier is 337 to assign each port an index that is unique within a given PE, 338 assign each PE an IP address that is unique within a given L1VPN 339 customer addressing realm (but need not be unique within the service 340 provider network), and then use a tuple 341 that acts as a port identifier. We'll refer to such port identifier 342 as the VPN-PPI. See Figure 2. 344 For L1VPNs it is a requirement that service provider operations are 345 independent of the VPN customer's addressing realm and the service 346 provider addressing realm is hidden from the customer. To achieve 347 this we have created two identifiers at the PE, one customer facing 348 and the other service provider facing. The PE IP address used for 349 the VPN-PPI is independent of the PE IP address used for the PPI (as 350 the two are taken from different address realms, the former from the 351 service provider's addressing realm and the latter from a VPN 352 customer's addressing realm). If for a given port on a PE, the PPI 353 and the VPN-PPI port identifiers are unnumbered, then they both 354 could use exactly the same port index. This is a mere convenience 355 since the PPI and VPN_PPI can be in any combination of valid 356 formats. 358 (Client realm) 359 +----+ +----+ 360 | | | | 361 | |CPI VPN-PPI | | 362 ---| CE |-----------------------------| PE |--- 363 | | | | 364 | | PPI | | 365 +----+ +----+ 366 (Provider realm) 368 Figure 2: Customer/Provider Port/Index Mapping 370 Note, as stated earlier, that IP addresses used for the CPIs, PPIs 371 and VPN-PPIs could be either IPv4, or IPv6 format addresses. 373 For a given link connecting a CE to a PE: 375 - if the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 376 address as well since VPN-PPI are created from the customer address 377 space. If the CPI is a , then the 378 VPN-PPI MUST be a for the same reason. 380 - if the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 381 address as well since VPN-PPI are created from the customer address 382 space. If the CPI is a , then the 383 VPN-PPI MUST be a for the same reason. 385 Note: for a given port on PE, whether the VPN-PPI of that port is an 386 IP address or a is independent of the 387 format of the PPI of that port. 389 This document assumes that assignment of the PPIs is controlled 390 solely by the service provider (without any coordination with the 391 L1VPN customers), while assignment of addresses used by the CPIs and 392 VPN-PPIs is controlled solely by the administrators of L1VPN. This 393 provides maximum flexibility. The L1VPN administrator is the entity 394 that controls the L1VPN service specifics for the L1VPN customers. 395 This function may be owned by the service provider but may also be 396 performed by a third party who has agreements with the service 397 provider. And, of course, each L1VPN customer could assign such 398 addresses on its own, without any coordination with other L1VPNs. 400 This document also requires that there is IP connectivity between 401 the CE and the PE as specified earlier. This connectivity could be 402 either a single IP hop, or a tunnel (GRE or IP-in-IP) or an IP 403 private network, or even an IP VPN for example. We'll refer to the 404 CE's address of this channel as the CE Control Channel Address (CE- 405 CC-Addr), and to the PE's address of this channel as the PE Control 406 Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are 407 REQUIRED to be unique within the L1VPN they belong to, but are not 408 REQUIRED to be unique across multiple L1VPNs. Control channel 409 addresses are not shared amongst multiple VPNs. Assignment of CE-CC- 410 Addr and PE-CC-Addr is controlled by the administrators of the 411 L1VPN. 413 Multiple ports on a CE could share the same control channel only as 414 long as all these ports belong to the same L1VPN. Likewise, multiple 415 ports on a PE could share the same control channel only as long as 416 all these ports belong to the same L1VPN. 418 4. Port Based L1VPN Basic Mode 420 An L1VPN is a port-based VPN service where a pair of CEs could be 421 connected through the service provider network via a GMPLS-based LSP 422 within a given VPN port topology. It is precisely this LSP that 423 forms the basic unit of the L1VPN service that the service provider 424 network offers. If a port by which a CE is connected to a PE 425 consists of multiple channels (e.g., multiple wavelengths), the CE 426 could establish LSPs to multiple other CEs in the same VPN over this 427 single port. 429 In the L1VPN, the service provider does not initiate the creation of 430 an LSP between a pair of CE ports. The LSP establishment is 431 initiated by the CE. However, the SP, by using the 432 mechanisms/toolkit outlined in this document, restricts the set of 433 other CE ports, which may be the remote endpoints of LSPs that have 434 the given port as the local endpoint. Subject to these restrictions, 435 the CE-to-CE connectivity is under the control of the CEs 436 themselves. In other words, the SP allows a L1VPN to have a certain 437 set of topologies (expressed as a port-to-port connectivity matrix. 438 CE-initiated signaling is used to choose a particular topology from 439 that set. 441 For each L1VPN that has at least one port on a given PE, the PE 442 maintains a Port Information Table (PIT) associated with that L1VPN. 443 This tables contains a list of tuples for all the ports 444 within its L1VPN. In addition, for local PE ports of a given L1VPN 445 the tuples also include the VPN-PPIs of these ports. 447 PE PE 448 +---------+ +--------------+ 449 +--------+ | +------+| | +----------+ | +--------+ 450 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 451 | CE1 |--| |PIT || Route | | PIT | |-| CE2 | 452 +--------+ | | ||<----------->| | | | +--------+ 453 | +------+|Dissemination| +----------+ | 454 | | | | 455 +--------+ | +------+| | +----------+ | +--------+ 456 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 457 | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 | 458 +--------+ | | || (Backbone ) | | | | +--------+ 459 | +------+| --------- | +----------+ | 460 | | | | 461 +--------+ | +-----+ | | +----------+ | +--------+ 462 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 463 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 464 +--------+ | | | | | | | | +--------+ 465 | +-----+ | | +----------+ | 466 +---------+ +--------------+ 468 Figure 3 Basic Mode L1VPN Service 470 4.1 L1VPN Port Information Tables 472 Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C with there 473 associated PITs. A PIT consists of local information as well as 474 remote information. It follows that PIT on a given PE is populated 475 from two information sources: 477 1. The information related to the CEs' ports attached to the ports 478 local to that PE. 479 2. The information about the CEs connected to the remote PEs 481 A PIT MAY be populated via provisioning or by auto-discovery 482 procedures. When provisioning is used the entire table MAY be 483 populated by provisioning commands either at a console or by a 484 management system which may have some automation capability. 485 As the network grows some form of automation is desirable. 487 For local information between a CE and a PE, a PE MAY leverage LMP 488 to populate the link information. This local 489 information also needs to be propagated to other PEs that share the 490 same VPN. The mechanisms for this are out of scope for this document 491 but the information needed to be exchanged is described in section 492 4.1.1. 494 The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a 495 PIT for each L1VPN for which it has member CEs locally attached. A 496 PE is does not need to maintain PITs for other L1VPNs. However, the 497 full set of PITs with all L1VPN entries for multiple VPNs MAY also 498 be available to all PEs. 500 The remote information in the context of a VPN identifier (i.e., the 501 remote CEs of this VPN) MAY also be sent to the local CE belonging 502 to the same VPN. Exchange of this information is outside the scope 503 of this document. 505 4.1.1. Local Auto-Discovery Information 507 The information that needs to be discovered on a PE local port is 508 the local CPI and the VPN-PPI. 510 This information MAY be configured or if LMP is used between the CE 511 and PE, LMP MAY be used to exchange this information. 513 Once a CPI has been discovered, the corresponding VPN-PPI maps in a 514 local context to a VPN Identifier and a corresponding PPI. 515 One way to enforce a provider controlled VPN context is to pre- 516 provision VPN-PPI's with a VPN identifier. Other policy mechanisms 517 to achieve this are outside the scope of this document. In this 518 manner, a relationship of a CPI to a VPN and PPI port can be 519 established when the port is provisioned as belonging to the VPN. 521 4.1.2. PE Remote Auto-Discovery Information 523 This section provides the information that is carried by any auto- 524 discovery mechanism, and is used to dynamically populate a PIT. The 525 information provides a single mapping. Each auto- 526 discovery mechanism will define the method(s) by which multiple 527 mappings are communicated, as well as invalidated. 529 This information should be consistent regardless of the mechanism use 530 to distribute the information [L1VPN-BGP-AD], [L1VPN-OSPF-AD]. 532 The format of encoding a single tuple is: 534 +---------------------------------------+ 535 | PPI Length (1 octet) | 536 +---------------------------------------+ 537 | PPI (variable) | 538 +---------------------------------------+ 539 | CPI AFI (2 octets) | 540 +---------------------------------------+ 541 | CPI (length) | 542 +---------------------------------------+ 543 | CPI (variable) | 544 +---------------------------------------+ 546 Figure 4: Auto-Discovery Information 548 The use and meaning of these fields are as follows: 550 PPI Length: 552 A one octet field whose value indicates the length of the PPI 553 field 555 PPI field: 557 A variable length field that contains the value of the PPI 558 (either an address or tuple 560 CPI AFI field: 562 A two octets field whose value indicates address family of the 563 CPI. 565 CPI Length: 567 A once octet field whose value indicates the length of the CPI 568 field. 570 CPI (variable): 572 A variable length field that contains the CPI value (either an 573 address or tuple. 575 tuples MUST also be associated with one or more globally 576 unique identifiers associated with a particular VPN. A globally 577 unique identifier can encode a VPN-ID, a route target, or any other 578 globally unique identifier. In this document we specify a generic 579 encoding format for the globally unique identifier common to all the 580 auto-discovery mechanisms. However, each auto-discovery mechanism 581 will define the specific method(s) by which the encoding is 582 distributed and the association with a tuple is made. 583 The encoding of the globally unique identifier associated with the 584 VPN is: 586 +------------------------------------------------+ 587 | L1vpn Globally unique identifier (8 octets) | 588 +------------------------------------------------+ 590 Figure 5: Auto-Discovery Globally unique identifier Format 592 4.2 CE to CE LSP Establishment 594 In order to establish an LSP, a CE needs to identify all other CEs 595 in the CE's L1VPN it wants to connect to. A CE may already have 596 obtained this information through provisioning or through some other 597 schemes (such schemes are outside the scope of this document). 599 Ports associated with a given CE-PE link, in addition to their CPI 600 and PPI MAY also have other information associated with them that 601 describes characteristics and constraints of the channels within 602 these ports, such as encoding supported by the channels, bandwidth 603 of a channel, total unreserved bandwidth within the port, etc. This 604 information could be further augmented with the information about 605 certain capabilities of the service provider network (e.g., support 606 regeneration section overhead (RSOH) Data Communications Channel 607 (DCC) transparency, arbitrary concatenation, etc.). This information 608 is used to ensure that ports at each end of an LSP have compatible 609 characteristics, and that there are sufficient unallocated resources 610 to establish an LSP between these ports. 612 It may happen that for a given pair of ports within an L1VPN, each 613 of the CEs connected to these ports would concurrently try to 614 establish an LSP to the other CE. If having a pair of LSPs between a 615 pair of ports is viewed as undesirable, the way to resolve this is 616 to require the CE with the lower value of the CPI to terminate the 617 LSP originated by the CE. This option could be controlled by 618 configuration on the CE devices. 620 4.3 Signaling 622 In L1VPN BM a CE needs to be configured with the CPIs of other 623 ports. Once a CE is configured with the CPIs of the other ports 624 within the same L1VPN, which we'll refer to as "target ports", the 625 CE uses a (subset of) GMPLS signaling, to request the provider 626 network to establish an LSP to a target port. 628 For inter-CE connectivity, the request originated by the CE contains 629 the CPI of the port on the CE that CE wants to use for the LSP, and 630 the CPI of the target port. When the PE attached to the CE that 631 originated the request receives the request, the PE identifies the 632 appropriate PIT, and then uses the information in that PIT to find 633 out the PPI associated with the CPI of the target port carried in 634 the request. The PPI should be sufficient for the PE to establish an 635 LSP. Ultimately the request reaches the CE associated with the 636 target CPI (note that the request still carries the CPI of the CE 637 that originated the request). If the CE associated with the target 638 CPI accepts the request, the LSP is established. 640 Note that a CE need not establish an LSP to every target port that 641 CE knows about - it is a local CE matter to select a subset of 642 target ports to which the CE will try to establish LSPs. 644 The procedures for establishing an individual connection between two 645 corresponding CEs is the same as the procedure specified for GMPLS 646 overlay [RFC4208]. 648 4.3.1 Signaling Procedures 650 When an ingress CE sends an RSVP Path message to an ingress PE, the 651 source IP address in the IP packet that carries the message is set 652 to the appropriate CE-CC-Addr, and the destination IP address in the 653 packet is set to the appropriate PE-CC-Addr. When the ingress PE 654 sends back to the ingress CE the corresponding Resv message, the 655 source IP address in the IP packet that carries the message is set 656 to the PE-CC-Addr, and the destination IP address is set to the CE- 657 CC-Addr. 659 Likewise, when an egress PE sends an RSVP Path message to an egress 660 CE, the source IP address in the IP packet that carries the message 661 is set to the appropriate PE-CC-Addr, and the destination IP address 662 in the packet is set to the appropriate CE-CC-Addr. When the egress 663 CE sends back to the egress PE the corresponding Resv message, the 664 source IP address in the IP packet that carries the message is set 665 to the CE-CC-Addr, and the destination IP address is set to the PE- 666 CC-Addr. 668 In addition to being used for IP addresses in the IP packet that 669 carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr 670 are also used in the Next/Previous Hop Address field of the IF_ID 671 RSVP_HOP object that is carried between CEs and PEs. 673 In the case where a link between CE and PE is a numbered non-bundled 674 link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 675 TLVs of the IF_ID RSVP HOP object that is carried between the CE and 676 PE. In the case where a link between CE and PE is an unnumbered non- 677 bundled link, the CPI and VPN-PPI of that link are used for the IP 678 Address field of the Type 3 TLV. In the case where a link between CE 679 and PE is a bundled link, the CPI and VPN-PPI of that link are used 680 for the IP Address field of the Type 3 TLVs. 682 Additional processing related to unnumbered links is described in 683 the "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID 684 TLV", and "Unnumbered Forwarding Adjacencies" sections of RFC 3477 685 [RFC3477]. 687 When an ingress CE originates a Path message to establish an LSP 688 from a particular port on that CE to a particular target port, the 689 CE uses the CPI of its port in the Sender Template object. If the 690 CPI of the target port is an IP address, then the CE uses it in the 691 Session object. And if the CPI of the target port is a tuple, then the CE uses the IP address part of the tuple 693 in the Session object, and the whole tuple as the Unnumbered 694 Interface ID subobject in the ERO. 696 There are two options for RSVP-TE sessions. One option is to have a 697 single RSVP-TE session end to end where the addresses of the 698 customer and the provider are swapped at the PE, termed shuffling. 699 The other options is when stitching or hierarchy is used to create 700 two LSP sessions, one between the provider PE(s) and another end to 701 end session between the CEs. 703 4.3.1.1 Shuffling Sessions 705 Shuffling sessions are used when the desire is to have a single LSP 706 originating at the CE and terminating at the far end CE. The 707 customer addresses are shuffled to provider addresses at the ingress 708 PE and back to customer addresses at the egress PE by using the 709 mapping provided by the PIT. 711 When the Path message arrives at the ingress PE, the PE selects the 712 PIT associated with the L1VPN, and then uses this PIT to map CPIs 713 carried in the Session and the Sender Template objects to the 714 appropriate PPIs. Once the mapping is done, the ingress PE replaces 715 CPIs with these PPIs. As a result, the Session and the Sender 716 Template objects that are carried in the GMPLS signaling within the 717 service provider network carry PPIs, and not CPIs. The egress PE 718 performs the reverse mapping - it maps PPIs carried in the Session 719 and the Sender Template object into the appropriate CPIs, and then 720 sends the Path message to the egress CE that has the target port. 721 This translation of addresses and session ids is termed shuffling 722 and driven by the L1VPN Port information tables (see section 4). 723 This MUST be performed for all RSVP-TE Messages at the PE edges. In 724 this case there is one CE to CE session. 726 At the egress PE, the reverse mapping operation is performed. The PE 727 extracts the ingress/egress PPI values carried in the 728 SENDER_TEMPLATE and SESSION objects (respectively). The egress PE 729 identifies the appropriate PIT to find out the appropriate CPI 730 associated with the PPI of the egress CE. Once the mapping is 731 retrieved, the egress PE replaces the ingress/egress PPI values with 732 the corresponding CPI values. As a result, the SESSION and the 733 SENDER_TEMPLATE objects included in the GMPLS RSVP-TE Path message 734 sent from the egress PE to the egress CE carry CPIs, and not PPIs. 735 Here also, for the GMPLS RSVP-TE Path messages sent from the egress 736 PE to CE, the source IP address (of the IP packet carrying this 737 message) is set to the appropriate PE-CC-Addr, and the destination 738 IP address (of the IP packet carrying this message) is set to the 739 appropriate CE-CC-Addr. 741 At this point the CE's view is a single LSP point to point between 742 the two CEs with a virtual link between the PE nodes. CE-PE(-)PE- 743 CE. The L1VPN PE nodes have a view of the PE-PE LSP in all its 744 detail. The PEs MAY filter the RSVP-TE signaling removing 745 information about the provider topology and replacing it with a view 746 of a virtual link. 748 4.3.1.2 Stitched or Nested Sessions 749 Stitching or Nesting options are dependent on the LSP switching 750 types. If the CE to CE and PE to PE LSPs are identical in switching 751 type and capacity the LSP MAY be stitched together and the 752 procedures in [GMPLS-STITCHING] apply. If the CE to CE LSPs and the 753 PE to PE LSPs are of not the same switching type or of different but 754 compatible capacity the LSPs MAY be Nested and the procedures for 755 [RFC4206] apply. The Stitched and Nested LSP signaling are 756 analogous procedures and can be discussed together. 758 When the Path Message arrives at the ingress PE, the PE selects the 759 PIT associated with the L1VPN, and then uses this PIT to map CPIs 760 carried in the Session and the Sender Template objects to the 761 appropriate PPIs. Once the mapping is done, a new PE to PE session 762 is established with the parameters compatible with the CE session. 763 Upon successful establishment of the PE to PE session, the CE 764 signaling request is sent to the egress PE. 766 At the ingress PE when stitching and nesting are used a PE to PE 767 session is established. This could be achieved by several means: 768 - Associating an already established PE-PE FA-LSP or LSP to the 769 destination that meets the requested parameters. 770 - Establishing a compliant PE-PE LSP. 772 At this point the CE's view is a single LSP point to point between 773 the two CEs with a virtual node the PE nodes. CE-PE(-)PE-CE. The 774 L1VPN PE nodes have a view of the PE-PE LSP in all its detail. The 775 PEs do not have filter the RSVP-TE signaling removing information 776 about the provider topology because the PE-PE signaling is not 777 visible to the CE nodes. 779 4.3.1.3 Other Signaling 781 An ingress PE may receive and potentially reject a Path message that 782 contains an Explicit Route Object and so cause the switched 783 connection setup to fail. However, the ingress PE may accept EROs, 784 which include a sequence of {}. 787 - Path message without ERO: when an ingress PE receives a Path 788 message from an ingress CE that contains no ERO, it MUST calculate a 789 route to the destination for the PE-to-PE LSP and include that route 790 in an ERO, before forwarding the Path message. One exception would 791 be if the egress core node were also adjacent to this core node. 793 - Path message with ERO: when an ingress PE receives a Path message 794 from an ingress CE that contains an ERO (of the form detailed 795 above), the former computes a path to reach the egress PE. It then 796 inserts this path as part of the ERO before forwarding the Path 797 message. 799 In the case of Shuffling the overlay rules for Notification and RRO 800 Processing are identical to the UNI or Overlay Model[RFC4208] which 801 state that Edge PE MAY remove/edit Provider Notification and RRO 802 objects when passing the messages to the CEs. 804 4.4 Recovery Procedures 806 Signaling: 808 A CE requests network protected (from PE-to-PE) LSP by using 809 [RFC4873] technique. Dynamic identification of merge nodes is 810 supported via the LSP Segment Recovery Flags carried in the 811 Protection object (see Section 6.2 of [RFC4873]). 813 Notification: 815 A Notify Request object MAY be inserted in Path or Resv messages to 816 indicate the address of a CE that should be notified of an LSP 817 failure. Notifications MAY be requested in both the upstream and 818 downstream directions: 820 o) Upstream notification is indicated via the inclusion of a Notify 821 Request Object in the corresponding Path message. 823 o) Downstream notification is indicated via the inclusion of a 824 Notify Request Object in the corresponding Resv message. 826 A PE receiving a message containing a Notify Request object SHOULD 827 store the Notify Node Address in the corresponding state block. The 828 PE SHOULD also include a Notify Request object in the outgoing Path 829 or Resv message. The outgoing Notify Node Address MAY be updated 830 based on local policy. This means that a PE upon reception of this 831 object from the CE MAY update its value. 833 If the ingress CE includes a NOTIFY_REQUEST object into the Path 834 message, the ingress PE MAY replace the received 'IPv4 Notify Node 835 Address' by its own selected 'IPv4 Notify Node Address', and in 836 particular the local TE Router_ID. The Notify Request Object MAY be 837 carried in Path or Resv messages (Section 7 of [RFC3473]). The 838 format of the NOTIFY_REQUEST object is defined in [RFC3473]. 840 Inclusion of a NOTIFY_REQUEST object is used to request the 841 generation of notifications upon failure occurrence but does not 842 guarantee that a Notify message will be generated. 844 5. Security Considerations 846 Since association of a particular port with a particular L1VPN (or 847 to be more precise with a particular PIT) is done by the service 848 provider as part of the service provisioning process (and thus can't 849 be altered via signaling between CE and PE), and since signaling 850 between CE and PE is assumed to be over a private network (and thus 851 can't be spoofed by entities outside the private network), the 852 solution described in this document doesn't require authentication 853 in signaling. 855 6. IANA Considerations 857 This document makes no requests for IANA action. 859 7. Intellectual Property Considerations 861 The IETF takes no position regarding the validity or scope of any 862 Intellectual Property Rights or other rights that might be claimed 863 to pertain to the implementation or use of the technology described 864 in this document or the extent to which any license under such 865 rights might or might not be available; nor does it represent that 866 it has made any independent effort to identify any such rights. 867 Information on the procedures with respect to rights in RFC 868 documents can be found in BCP 78 and BCP 79. 870 Copies of IPR disclosures made to the IETF Secretariat and any 871 assurances of licenses to be made available, or the result of an 872 attempt made to obtain a general license or permission for the use 873 of such proprietary rights by implementers or users of this 874 specification can be obtained from the IETF on-line IPR repository 875 at http://www.ietf.org/ipr. 877 The IETF invites any interested party to bring to its attention any 878 copyrights, patents or patent applications, or other proprietary 879 rights that may cover technology that may be required to implement 880 this standard. Please address the information to the IETF at ietf- 881 ipr@ietf.org. 883 8. References 885 8.1 Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, March 1997. 890 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 891 Switching(GMPLS)User-Network Interface (UNI): Resource 892 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 893 for the Overlay Model", RFC 4208, October 2005. 895 [RFC3471] Berger, L. (editor), "Generalized MPLS -Signaling 896 Functional Description", January 2003, RFC3471. 898 [RFC3473] Berger, L. (editor), "Generalized MPLS Signaling - RSVP-TE 899 Extensions", RFC3473, January 2003. 901 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support 902 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, 903 October 2005. 905 [RFC4204] J. Lang (editor), "Link Management Protocol (LMP)," RFC 906 4204, October 2005. 908 [GMPLS-STITCHING] A. Ayyangar, Ed., J.P. Vasseur, A. Farrel, "Label 909 Switched Path Stitching with Generalized MPLS Traffic 910 Engineering", work in progress. 912 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 913 Hierarchy with Generalized Multi-Protocol Label Switching 914 (GMPLS)Traffic Engineering (TE)", RFC 4206, October 2005. 916 [L1VPN-FRAMEWORK] Takeda, T (editor), "Framework and Requirements 917 for Layer 1 Virtual Private Networks", work in progress. 919 [L1VPN-APPLIC] Takeda, T (editor), "Applicability Statement for 920 Layer 1 Virtual Private Networks (L1VPNs) Basic Mode", work in 921 progress. 923 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. Farrel, A., 924 "GMPLS Based Segment Recovery", RFC 4873, May 2007. 926 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 927 Links in Resource ReSerVation Protocol - Traffic Engineering 928 (RSVP-TE)", RFC 3477, January 2003. 930 8.2 Informative References 932 [RFC3945] E. Mannie (editor), "Generalized Multi-Protocol Label 933 Switching (GMPLS) Architecture" RFC3945, October 2004 935 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 936 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 938 [L1VPN-BGP-AD] Ould-Brahim, H., Fedyk, D., Rekhter, Y., "BGP-based 939 Auto-Discovery for L1VPNs", work in progress. 941 [L1VPN-OSPF-AD] Bryskin, I., Berger, Lou "OSPF Based L1VPN Auto- 942 Discovery", work in progress. 944 9. Acknowledgments 946 The authors would like to thank Adrian Farrel, Hamid Ould-Brahim and 947 Tomonori Takeda for their valuable comments. 949 9. Author's Addresses 951 Don Fedyk 952 Nortel Networks 953 600 Technology Park 954 Billerica, Massachusetts 955 01821 U.S.A 956 Phone: +1 (978) 288 3041 957 Email: dwfedyk@nortel.com 959 Yakov Rekhter 960 Juniper Networks 961 1194 N. Mathilda Avenue 962 Sunnyvale, CA 94089 963 Email: yakov@juniper.net 965 Dimitri Papadimitriou (Alcatel) 966 Fr. Wellesplein 1, 967 B-2018 Antwerpen, Belgium 968 Phone: +32 3 240-8491 969 Email: dimitri.papadimitriou@alcatel.be 971 Richard Rabbat 972 Google, Inc 973 1600 Amphitheatre Pkwy 974 Mountain View, CA 95054 975 Email: rabbat@alum.mit.edu 977 Lou Berger 978 LabN Consulting, LLC 979 Phone: +1 301-468-9228 980 EMail: lberger@labn.net 982 10. Disclaimer of Validity 984 "This document and the information contained herein are provided on 985 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 986 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 987 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 988 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 989 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 990 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 991 PARTICULAR PURPOSE. 993 11. Copyright Statement 995 Copyright (C) The IETF Trust (2008). 997 This document is subject to the rights, licenses and restrictions 998 contained in BCP 78, and except as set forth therein, the authors 999 retain all their rights.