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