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