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