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