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