idnits 2.17.1 draft-fedyk-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 643: '...gress CE that contains no ERO, it MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6765 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 114, but not defined == Missing Reference: 'GMPLS-Overlay' is mentioned on line 123, but not defined == Missing Reference: 'GMPLS-Arch' is mentioned on line 244, but not defined == Missing Reference: 'NSAP-IPv6' is mentioned on line 276, but not defined == Missing Reference: 'BGP-COMM' is mentioned on line 479, but not defined == Unused Reference: 'L1VPN-REQ' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SIGNALING' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'GMPLS-HIERARCHY' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'NSAP-IPV6' is defined on line 747, 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-OVERLAY' == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 -- Obsolete informational reference (is this intentional?): RFC 1888 (ref. 'NSAP-IPV6') (Obsoleted by RFC 4048) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group Don Fedyk 3 Internet Draft Nortel 4 Expiration Date: March 2006 Yakov Rekhter 5 Juniper Networks 6 (Editors) 7 October 2005 9 Layer 1 VPN Basic Mode 11 draft-fedyk-l1vpn-basic-mode-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or 18 she becomes aware will be disclosed, in accordance with Section 19 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- 29 Drafts as reference material or to cite them other than as 30 "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed 35 at http://www.ietf.org/shadow.html. 37 Abstract 39 This draft describes the basic mode of Layer 1 VPNs (L1VPN BM) 40 that is port based VPNs. In L1VPN BM, the basic unit of service 41 is a Label Switched Path (LSP) between a pair of customer ports 42 within a given VPN port-topology. This draft defines the 43 operational model using either provisioning or a VPN auto- 44 discovery mechanism and the signaling extensions for the L1VPN 45 BM. This draft uses BGP as an example of the auto-discovery 46 mechanism. 48 Table of Contents 50 1. Introduction..................................................2 51 2. Layer 1 VPN Services..........................................3 52 3. Addressing, Ports, Links and Control Channels.................5 53 3.1 Service Provider Realm.......................................6 54 3.2 Layer 1 Ports and Index......................................6 55 3.3 Port and Index Mapping.......................................7 56 4. Port Based L1VPN Basic Mode...................................8 57 4.1 L1VPN Port Information Tables................................9 58 4.2 CE to CE LSP Establishment..................................10 59 4.3 Signaling...................................................11 60 4.3.1 Signaling Procedures......................................12 61 5. Security Considerations......................................14 62 6. IANA Considerations..........................................14 63 7. Intellectual Property Considerations.........................14 64 8. References...................................................15 65 8.1 Normative References........................................15 66 8.2 Informative References......................................15 67 9. Author's Addresses...........................................16 68 10. Disclaimer of Validity......................................17 69 11. Full Copyright Statement....................................17 71 1. Introduction 73 In this document, we consider a service provider network that 74 consists of devices that support GMPLS (e.g., Lambda Switch 75 Capable devices, Optical Cross Connect, SDH Cross Connect, 76 etc.). We partition these devices into P (provider) and PE 77 (provider edge) devices. In the context of this document we'll 78 refer to the former devices as just "P", and to the latter 79 devices as just "PE". The Ps are connected only to the devices 80 within the provider's network. The PEs are connected to the 81 other devices within the provider network (either Ps, or PEs), 82 as well as to the devices outside of the provider network. 83 We'll refer to such other devices as Client Edge Devices (CEs). 84 An example of a CE would be a router, an SDH cross-connect, or 85 an Ethernet switch. 87 The [GMPLS-OVERLAY] draft is the basis for signaling from the 88 CE to the PE. In the [GMPLS-OVERLAY] draft the terms Core Node 89 (CN) and Edge Node (EN) correspond to PE and CE respectively. 91 +---+ +---+ 92 | P | | P | 93 +---+ +---+ 94 PE / \ PE 95 +-----+ +-----+ +--+ 96 | | | |----| | 97 +--+ | | | | |CE| 98 |CE|----+-----+ | |----| | 99 +--+\ | | | +--+ 100 \ +-----+ | | 101 \ | | | | +--+ 102 \| | | |----|CE| 103 +-----+ +-----+ +--+ 104 \ / 105 +---+ +---+ 106 | P |....| P | 107 +---+ +---+ 109 Figure 1: Generalized Layer 1 VPN Reference Model 111 This draft specifies how the L1VPN Basic Mode (BM) service can 112 be realized using VPN auto-discovery and Generalized Multi- 113 Protocol Label Switching (GMPLS)Signaling [GMPLS-RSVP-TE], 114 Routing [GMPLS-Routing] and LMP [GMPLS-LMP] mechanisms. The 115 L1VPN auto-discovery has similar requirements to the L3VPNs 116 auto-discovery [L3VPN-REQ]. As with L3VPNs there are protocol 117 options to be made with auto-discovery. For illustration 118 purposes BGP is used as a protocol example but other protocols 119 or methods of VPN distribution may be equally well suited. 120 GMPLS routing and signaling are used without extensions within 121 the provider network to establish and maintain Lambda Switch 122 Capable (LSC) or SONET/SDH (TDM) connections between provider 123 nodes. This follows the model in [GMPLS-Overlay]. LMP can be 124 used to automate link discovery and augment routing as well as 125 failure handling capabilities. 127 2. Layer 1 VPN Services 129 Layer 1 services on the interfaces of customer and provider 130 ports could be any of the L1 interfaces supported by GMPLS. 131 Since the mechanisms specified here use GMPLS as the signaling 132 mechanism, and since GMPLS applies to both SONET/SDH (TDM) and 133 Lambda Switch Capable (LSC) interfaces, it results that L1VPN 134 services includes but is not restricted to Lambda Switch 135 Capable or TDM based equipment. Note that this document 136 describes Basic Mode L1 VPNs and as such assumes that (1) GMPLS 137 RSVP-TE is used for signaling both within the service provider 138 (between PEs), as well as between the customer and the service 139 provider (between CE and PE); (2) GMPLS RSVP-TE is used not 140 just as a signaling mechanism, but also as a routing mechanism 141 within the provider network. Basic Mode L1 VPNs do not assume 142 for GMPLS Routing on the CE-PE link since outside the scope of 143 a basic mode of operation. 145 A CE is connected to a PE via one or more links. In the context 146 of this document a link is the same as a GMPLS Traffic 147 Engineering (TE) link construct, as defined in [GMPLS-ROUTING]. 148 In the context of this document a link is a logical construct 149 that is a member of a VPN hence introducing the notion of 150 membership to a set of CEs forming the VPN. Interfaces at the 151 end of each link could be any of the interfaces that are 152 supported by GMPLS. Likewise, CEs and PEs could be any devices 153 that are supported by GMPLS (e.g., optical cross connects, SDH 154 cross-connects, LSRs, etc). 156 Each link may consist of one or more channels or sub-channels 157 (e.g., wavelength or wavelength and timeslot respectively). For 158 the purpose of this discussion we assume that all the channels 159 within a given link have shared similar characteristics (e.g., 160 switching capabilities, encoding, type, etc_), and can be 161 selected independently from the CE's point of view. Channels on 162 different links of a CE need not have the same characteristics. 164 There may be more than one link between a given CE PE pair. A 165 CE may be connected to more than one PE (with at least one port 166 per each PE). And, of course, a PE may have more than one CE 167 from different VPNs connected to it. 169 If a CE is connected to a PE via multiple links and all these 170 links belong to the same VPN, then for the purpose of this 171 document these links could be treated as a single link using 172 the link bundling constructs [LINK-BUNDLING]. 174 A link may have only data bearing channels, or only control 175 bearing channels, or both. For the purpose of this discussion 176 we assume that for a given CE-PE pair at least one of the links 177 between them has at least one data bearing channel, and at 178 least one control bearing channel, or there is IP reachbility 179 between the CE and the PE that could be used to exchange 180 control information. 182 A point-to-point link has two end-points - one on the CE and 183 one on the PE. In the context of this document we'll refer to 184 the former as "CE port", and to the latter as "PE port". From 185 the above it follows that a CE is connected to a PE via one or 186 more ports, where each port may consist of one or more channels 187 or sub-channels (e.g., wavelength or wavelength and timeslot 188 respectively), and all the channels within a given port have 189 shared similar characteristics (e.g., capabilities, encoding, 190 etc_), and can be interchanged from the CEs point of view. Just 191 like links, in the context of this document, ports are logical 192 construct that are used to represent grouping of physical 193 resources on a per L1VPN basis that are used to connect a CE to 194 a PE. 196 At any given point in time, a given port on a PE is associated 197 with at most one L1VPN, or to be more precise with at most one 198 Port Information Table maintained by the PE (although different 199 ports on a given PE could be associated with different L1VPNs, 200 or to be more precise with different Port Information Tables). 201 The association of a port with a VPN may defined by 202 provisioning the relationship on the provider devices. In other 203 words the context of a VPN membership in Basic mode is enforced 204 by service provider control. 206 This document assumes that the interface between the CE and PE 207 used for the purpose of signaling is capable to 208 initiate/process GMPLS protocols messages [GMPLS-RSVP-TE] and 209 follows the procedures described in [GMPLS-OVERLAY]. 211 An important goal of L1VPN services (particularly with respect 212 to basic mode services) is the ability to support what is known 213 as "single end provisioning", where the addition of a new port 214 to a given L1VPN would involve configuration changes only on 215 the PE that has this port. The extension of this model to the 216 CE is outside the scope of the L1VPN BM. In L1VPN BM a CE 217 device could be provisioned with the corresponding port 218 information in much the same manner an overlay service is 219 provisioned today. 220 Another important goal in the L1VPN service is the ability to 221 establish/terminate an LSP between a pair of (existing) ports 222 within a L1VPN from the CE devices without involving 223 configuration changes in any of the provider's devices. In 224 other words, the VPN topology is under the CE device control. 226 The mechanisms outlined in this document aim at achieving these 227 above goals. Specifically, as part of the L1VPN service 228 offering, these mechanisms (1) enable the service provider to 229 restrict the set of ports to which a given port could be 230 connected, (2) enable a CE to establish the actual LSP to a 231 subset of ports. Finally, the mechanisms allow arbitrary L1VPN 232 topologies to be supported ranging from hub-and-spoke to full 233 mesh point to point connections. Other more advanced service and 234 topology support such as point to multi point (P2MP) services 235 etc. is for further study. 237 The L1VPN BM draft does not specify the exchange of CE routing 238 or topology information to the provider. This type of 239 information is not precluded from the architecture but is 240 beyond the scope of this document. 242 3. Addressing, Ports, Links and Control Channels 243 GMPLS established conventions for Addressing and link numbering 244 are discussed in the [GMPLS-Arch] documents. This section 245 builds on those definitions for the L1VPN case where we now 246 have Customer and Provider addresses in a Layer 1 Context. 248 3.1 Service Provider Realm 250 This document assumes that a service provider, or a group of 251 service providers that collectively offer L1VPN service, have a 252 single addressing realm that spans all PE devices involved in 253 providing the L1VPN service. This is necessary to enable GMPLS 254 mechanisms for path establishment and maintenance. We will 255 refer to this realm as the service provider addressing realm. 256 This document further assumes that each L1VPN customer has its 257 own addressing realm. We will refer to such realms as the 258 customer addressing realms. Customer addressing realms may 259 overlap with each other, and may also overlap with the service 260 provider addressing realm. 262 3.2 Layer 1 Ports and Index 264 Within a given L1VPN each port on a CE that connects the CE to 265 a PE has an identifier that is unique within that L1VPN (but 266 need not be unique across several L1VPNs). One way to construct 267 such an identifier is to assign each port an address that is 268 unique within a given L1VPN, and use this address as a port 269 identifier. Another way to construct such an identifier is to 270 assigned each port on a CE an index that is unique within that 271 CE, assign each CE an address that is unique within a given 272 L1VPN, and then use a tuple as a port 273 identifier. Note that both the port and the CE address may be 274 an address in several formats. This includes, but not limited 275 to IPv4, IPv6, and NSAP. Note that NSAP addresses may be 276 carried in IPv6 Fields as specified in [NSAP-IPv6]. This 277 identifier is part of the Customer Addressing Realm and is used 278 by the CE device to identify the CE port and the CE remote port 279 for signaling. CEs do not know or understand the Provider 280 Realm addresses. 282 Within a service provider network, each port on a PE that 283 connects that PE to a CE has an identifier that is unique 284 within that network. One way to construct such an identifier is 285 to assign each port on a PE an index that is unique within that 286 PE, assign each PE an IP address that is unique within the 287 service provider addressing realm, and then use a tuple as a port identifier within the provider 289 network. Another way to construct such an identifier is to 290 assign an IP address that is unique within the service provider 291 addressing realm to each such port. Either way, this IP address 292 is internal to the service provider network and is used for 293 GMPLS signaling within the service provider network. 295 As a result, each link connecting the CE to the PE is 296 associated with a CE port that has a unique identifier within a 297 given L1VPN, and with a PE port that has a unique identifier 298 within the service provider network. We'll refer to the former 299 as the customer port identifier (CPI), and to the latter as the 300 provider port identifier (PPI). 302 3.3 Port and Index Mapping 304 This document assumes that each PE port that has a PPI also has 305 an identifier that is unique within the L1VPN customer 306 addressing realm of the L1VPN associated with that port. One 307 way to construct such an identifier is to assign each port an 308 address that is unique within a given L1VPN customer addressing 309 realm, and use this address as a port identifier. Another way 310 to construct such an identifier is to assign each port an index 311 that is unique within a given PE, assign each PE an IP address 312 that is unique within a given L1VPN customer addressing realm 313 (but need not be unique within the service provider network), 314 and then use a tuple that acts as a 315 port identifier. We'll refer to such port identifier as the 316 VPN-PPI. 318 For L1VPNs it is a requirement that provider operations are 319 independent of the VPN customers addressing realm and the 320 provider addressing realm is hidden from the customer. To 321 achieve this we have created two identifies, one customer 322 facing and the other provider facing. The PE IP address used 323 for the VPN-PPI is independent of the PE IP address used for 324 the PPI (as the two are taken from different address realms, 325 the former from the provider's addressing realm and the latter 326 from a VPN customer's addressing realm). If for a given port on 327 a PE, the PPI and the VPN-PPI are both unnumbered, then they 328 both could use exactly the same port index. This is a mere 329 convenience since the PPI and VPN_PPI can be in any combination 330 of valid formats. 332 +----+ +----+ 333 | | | | 334 | |CPI VPN-PPI | | 335 ---| CE |-----------------------------| PE |--- 336 | | | | 337 | | PPI | | 338 +----+ +----+ 339 (Provider realm) 341 Figure 2: Customer/Provider Port/Index Mapping 343 Note, as stated earlier, that IP addresses used for the CPIs, 344 PPIs and VPN-PPIs could be either IPv4, IPv6 or NSAP addresses. 346 For a given link connecting a CE to a PE, if the CPI is an IP 347 address, then the VPN-PPI has to be an IP address as well. And 348 if the CPI is an , then the VPN-PPI 349 must be a . However, for a given 350 port on PE, whether the VPN-PPI of that port is an IP address 351 or a is independent of whether the 352 PPI of that port is an IP address or a . 355 This document assumes that assignment of the PPIs is controlled 356 solely by the service provider (without any coordination with 357 the L1VPN customers), while assignment of addresses used by the 358 CPIs and VPN-PPIs is controlled solely by the administrators of 359 L1VPN . The L1VPN administrator is the entity that controls the 360 L1VPN service specifics for the L1VPN customers. This function 361 may be owned by the service provider but may also be performed 362 by a third party who has agreements with the service provider. 363 And, of course, each L1VPN could assign such addresses on its 364 own, without any coordination with other L1VPNs. This document 365 also assumes that there is an IP control channel between the CE 366 and the PE. This channel could be either a single IP hop, or a 367 tunnel (GRE or IP-in-IP) or an IP private network, or even an 368 IP VPN for example. We'll refer to the CE's address of this 369 channel as the CE Control Channel Address (CE-CC-Addr), and to 370 the PE's address of this channel as the PE Control Channel 371 Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are 372 required to be unique within the L1VPN they belong to, but are 373 not required to be unique across multiple L1VPNs. Control 374 channel addresses are not shared amongst multiple VPNs. 375 Assignment of CE-CC-Addr and PE-CC-Addr are controlled by the 376 administrators of the L1VPN. 378 Multiple ports on a CE could share the same control channel 379 only as long as all these ports belong to the same L1VPN. 380 Likewise, multiple ports on a PE could share the same control 381 channel only as long as all these ports belong to the same 382 L1VPN. 384 4. Port Based L1VPN Basic Mode 386 An L1VPN is a port-based VPN service where a pair of CEs could 387 be connected through the service provider network via a GMPLS- 388 based LSP within a given VPN port topology. It is precisely 389 this LSP that forms the basic unit of the L1VPN service that 390 the service provider network offers. If a port by which a CE is 391 connected to a PE consists of multiple channels (e.g., multiple 392 wavelengths), the CE could establish LSPs to multiple other CEs 393 over this single port. 395 In the L1VPN, the service provider does not initiate the 396 creation of an LSP between a pair of PE ports. This is done 397 rather by the CEs, which attach to the ports. However, the SP, 398 by using the mechanisms/toolkit outlined in this document, 399 restricts the set of other PE ports, which may be the remote 400 endpoints of LSPs that have the given port as the local 401 endpoint. Subject to these restrictions, the CE-to-CE 402 connectivity is under the control of the CEs themselves. In 403 other words, the SP allows a L1VPN to have a certain set of 404 topologies (expressed as a port-to-port connectivity matrix; 405 CE-initiated signaling is used to choose a particular topology 406 from that set. 408 For each L1VPN that has at least one port on a given PE, the PE 409 maintains a port information table (PIT) associated with that 410 L1VPN. A PIT contains a list of tuples for all the 411 ports within its L1VPN. In addition, for local PE ports of a 412 given L1VPN the tuples also include the VPN-PPIs of these 413 ports. 415 PE PE 416 +---------+ +--------------+ 417 +--------+ | +------+| | +----------+ | +--------+ 418 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 419 | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | 420 +--------+ | | ||<----------->| | | | +--------+ 421 | +------+| Distribution| +----------+ | 422 | | | | 423 +--------+ | +------+| | +----------+ | +--------+ 424 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 425 | CE1 |--| |PIT ||--( GMPLS )-| | PIT | |-| CE2 | 426 +--------+ | | || (Backbone ) | | | | +--------+ 427 | +------+| --------- | +----------+ | 428 | | | | 429 +--------+ | +-----+ | | +----------+ | +--------+ 430 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 431 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 432 +--------+ | | | | | | | | +--------+ 433 | +-----+ | | +----------+ | 434 +---------+ +--------------+ 436 Figure 3 Basic Mode L1VPN Service 438 4.1 L1VPN Port Information Tables 440 A PIT may be populated entirely by provisioning. This allows 441 the PE to PE ports to be connected on demand. This means that 442 the table entries are provisioned either on each PE box for 443 each corresponding L1VPN or on a provisioning system in the 444 provider control. This may or may not mean that CE addresses 445 are entered multiple times on multiple PEs. As the network 446 grows some form of automation is desirable. 448 The PIT is by nature VPN-specific in that entries for a L1VPN 449 are only required on a PE if that PE locally supports that 450 L1VPN by having CEs belonging to that VPN attached to the PE. 451 However, the full set of PITs with all L1VPN entries for 452 multiple VPNs may also be available to all PEs. 454 Another option is to have an auto-discovery mechanism; for 455 example BGP Auto-discovery could be modified for L1VPN. L1VPN 456 auto-discovery has the advantage of reducing the configuration 457 for L1VPNs which could be desirable in large VPNs. 459 A PIT on a given PE is populated from two sources: 461 1. The information related to the CEs' ports attached to the 462 ports on that PE (this information could be optionally 463 received from the CEs, however in Basic Mode we assume 464 this information is provisioned.) Beyond Basic Mode this 465 information could be discovered by several mechanism such 466 as LMP, IGPs or BGP. 467 2. The information received from other PEs. This is the 468 information that is auto-discovered within the Provider 469 Network. 471 We'll refer to the former as the "local" information, and to 472 the latter as the "remote" information. 474 A way to propagate this local information to other PEs is by 475 using BGP VPN auto-discovery procedures, as specified in [BGP- 476 VPN-AUTODISCOVERY]. In this case to restrict the flow of this 477 information to only the PITs within a given L1VPN, we use BGP 478 route filtering based on the Route Target Extended Community 479 [BGP-COMM], as follows: 481 Each PIT on a PE is configured with one or more Route Target 482 Communities, called "Export Route Targets" that are used to tag 483 the local information when it is exported into provider's BGP. 484 The granularity of such tagging could be as fine as a single 485 pair. In addition, each PIT on a PE is configured 486 with one or more Route Target Communities, called "Import Route 487 Targets". Import Route Targets restrict the set of routes that 488 could be imported from the provider's BGP into the PIT to only 489 those routes that include at least one of these Communities. 491 When a service provider adds a new L1VPN port to a particular 492 PE, this port is associated at provisioning time with a PIT on 493 that PE, and this PIT is associated (again at provisioning 494 time) with that L1VPN. 496 For the purpose of L1VPN BM the CE only knows the local CPI 497 addresses and the remote CPI Addresses. 499 4.2 CE to CE LSP Establishment 500 In order to establish an LSP, a CE needs to identify all other 501 CEs in the CE's L1VPN it wants to connect to. A CE may already 502 have obtained this information through provisioning or through 503 some other schemes (such schemes are outside the scope of this 504 document). 506 Ports associated with a given CE-PE link, in addition to their 507 CPI and PPI may also have other information associated with 508 them that describes characteristics and constraints of the 509 channels within these ports, such as encoding supported by the 510 channels, bandwidth of a channel, total unreserved bandwidth 511 within the port, etc. This information could be further 512 augmented with the information about certain capabilities of 513 the Service Provider network (e.g., support RSOH DCC 514 transparency, arbitrary concatenation, etc.). This information 515 is used to ensure that ports at each end of an LSP have 516 compatible characteristics, and that there are sufficient 517 unallocated resources to establish an LSP between these ports. 519 It may happen that for a given pair of ports within an L1VPN, 520 each of the CEs connected to these ports would concurrently try 521 to establish an LSP to the other CE. If having a pair of LSPs 522 between a pair of ports is viewed as undesirable, the way to 523 resolve this is to require the CE with the lower value of the 524 CPI to terminate the LSP originated by the CE. This option 525 could be controlled by configuration on the CE devices. 527 4.3 Signaling 529 In L1VPN BM a CE needs to be configured with the CPIs of other 530 ports. Once a CE is configured with the CPIs of the other ports 531 within the same L1VPN, which we'll refer to as "target ports", 532 the CE uses a (subset of) GMPLS signaling, to request the 533 provider network to establish an LSP to a target port. 535 For inter-CE connectivity, the request originated by the CE 536 contains the CPI of the port on the CE that CE wants to use for 537 the LSP, and the CPI of the target port. When the PE attached 538 to the CE that originated the request receives the request, the 539 PE identifies the appropriate PIT, and then uses the 540 information in that PIT to find out the PPI associated with the 541 CPI of the target port carried in the request. The PPI should 542 be sufficient for the PE to establish an LSP. Ultimately the 543 request reaches the CE associated with the target CPI (note 544 that the request still carries the CPI of the CE that 545 originated the request). If the CE associated with the target 546 CPI accepts the request, the LSP is established. 548 Note that a CE need not establish an LSP to every target port 549 that CE knows about - it is a local CE matter to select a 550 subset of target ports to which the CE will try to establish 551 LSPs. 553 The procedures for establishing an individual connection 554 between two corresponding CEs is the same as the procedure 555 specified for GMPLS overlay. [GMPLS-OVERLAY] 557 4.3.1 Signaling Procedures 559 When a CE sends an RSVP Path message to a PE, the source IP 560 address in the IP packet that carries the message is set to the 561 appropriate CE-CC-Addr, and the destination IP address in the 562 packet is set to the appropriate PE-CC-Addr. When the PE sends 563 back to the CE the corresponding Resv message, the source IP 564 address in the IP packet that carries the message is set to the 565 PE-CC-Addr, and the destination IP address is set to the CE-CC- 566 Addr. 568 Likewise, when a PE sends an RSVP Path message to a CE, the 569 source IP address in the IP packet that carries the message is 570 set to the appropriate PE-CC-Addr, and the destination IP 571 address in the packet is set to the appropriate CE-CC-Addr. 572 When the CE sends back to the PE the corresponding Resv 573 message, the source IP address in the IP packet that carries 574 the message is set to the CE-CC-Addr, and the destination IP 575 address is set to the PE-CC-Addr. 577 In addition to being used for IP addresses in the IP packet 578 that carries RSVP messages between CE and PE, CE-CC-Addr and 579 PE-CC-Addr are also used in the Next/Previous Hop Address field 580 of the IF_ID RSVP_HOP object that is carried between CEs and 581 PEs. 583 In the case where a link between CE and PE is a numbered non- 584 bundled link, the CPI and VPN-PPI of that link are used for the 585 Type 1 or 2 TLVs of the IF_ID RSVP HOP object that is carried 586 between the CE and PE. In the case where a link between CE and 587 PE is an unnumbered non-bundled link, the CPI and VPN-PPI of 588 that link are used for the IP Address field of the Type 3 TLV. 589 In the case where a link between CE and PE is a bundled link, 590 the CPI and VPN-PPI of that link are used for the IP Address 591 field of the Type 3 TLVs. 593 When a CE originates a Path message to establish an LSP from a 594 particular port on that CE to a particular target port the CE 595 uses the CPI of its port in the Sender Template object. If the 596 CPI of the target port is an IP address, then the CE uses it in 597 the Session object. And if the CPI of the target port is a 598 tuple, then the CE uses the IP address 599 part of the tuple in the Session object, and the whole tuple as 600 the Unnumbered Interface ID subobject in the ERO. When the Path 601 message arrives at the ingress PE, the PE selects the PIT 602 associated with the L1VPN, and then uses this PIT to map CPIs 603 carried in the Session and the Sender Template objects to the 604 appropriate PPIs. Once the mapping is done, the ingress PE 605 replaces CPIs with these PPIs. As a result, the Session and the 606 Sender Template objects that are carried in the GMPLS signaling 607 within the service provider network carry PPIs, and not CPIs. 608 At the egress PE, the PE performs the reverse mapping - it maps 609 PPIs carried in the Session and the Sender Template object into 610 the appropriate CPIs, and then sends the Path message to the CE 611 that has the target port. 613 At the egress PE, the reverse mapping operation is performed. 614 The PE extracts the ingress/egress PPI values carried in the 615 SENDER_TEMPLATE and SESSION objects (respectively). The egress 616 PE identifies the appropriate PIT to find out the appropriate 617 CPI associated with the PPI of the egress CE. Once the mapping 618 is retrieved, the egress PE replaces the ingress/egress PPI 619 values with the corresponding CPI values. As a result, the 620 SESSION and the SENDER_TEMPLATE objects included in the GMPLS 621 RSVP-TE Path message sent from the egress PE to the egress CE 622 carry CPIs, and not PPIs. Here also, for the GMPLS RSVP-TE Path 623 messages sent from the egress PE to CE, the source IP address 624 (of the IP packet carrying this message) is set to the 625 appropriate PE-CC-Addr, and the destination IP address (of the 626 IP packet carrying this message) is set to the appropriate CE- 627 CC-Addr. 629 When the Path message reaches the egress CE, and gets 630 processed, the latter initiates towards the egress PE the 631 exchange of the Resv message. Here, the FILTER_SPEC object is 632 process similarly to the SENDER_TEMPLATE object. Both egress 633 and ingress PE (in sequence), performs the same mapping 634 operation as with the corresponding Path message. Once the Resv 635 message reaches the ingress CE, the switched connection is 636 established. 637 An ingress PE may receive and potentially reject a Path message 638 that contains ERO (Explicit Route Object), or ERO and so cause 639 the switched connection setup to fail. However, the ingress PE 640 may accept EROs, which include a sequence of []. 642 - Path message without ERO: when an ingress PE receives a 643 Path message from an ingress CE that contains no ERO, it MUST 644 calculate a route to the destination for the PE-to-PE LSP and 645 include that route in a ERO, before forwarding the Path 646 message. One exception would be if the egress core node were 647 also adjacent to this core node. 648 - Path message with ERO: when an ingress PE receives a Path 649 message from an ingress CE that contains an ERO (of the form 650 detailed above), the former computes a path to reach to reach 651 the egress PE. It then inserts this path as part of the ERO 652 before forwarding the Path message. 654 An ingress or an egress PE may include an RECORD_ROUTE object 655 and remove/filter the RRO from the received Path message before 656 forwarding it. Further an egress or an ingress PE may 657 remove/filter the RRO from a Resv message before forwarding it. 658 Filtering a RRO consist in editing its content and include only 659 the subobjects based on a local or global policy. This allows 660 the ingress/egress CE to be aware of the selected link and 661 labels on the egress/ingress CE side, respectively, for the 662 switched connections constituting this L1VPN. 664 The exact format of the extensions is TBD in a future revision. 666 5. Security Considerations 668 Since association of a particular port with a particular L1VPN 669 (or to be more precise with a particular PIT) is done by the 670 service provider as part of the service provisioning process 671 (and thus can't be altered via signaling between CE and PE), 672 and since signaling between CE and PE is assumed to be over a 673 private network (and thus can't be spoofed by entities outside 674 the private network), the solution described in this document 675 doesn't require authentication in signaling. 677 6. IANA Considerations 679 This document makes no requests for IANA action. 681 7. Intellectual Property Considerations 683 The IETF takes no position regarding the validity or scope of 684 any Intellectual Property Rights or other rights that might be 685 claimed to pertain to the implementation or use of the 686 technology described in this document or the extent to which 687 any license under such rights might or might not be available; 688 nor does it represent that it has made any independent effort 689 to identify any such rights. Information on the procedures with 690 respect to rights in RFC documents can be found in BCP 78 and 691 BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of 695 an attempt made to obtain a general license or permission for 696 the use of such proprietary rights by implementers or users of 697 this specification can be obtained from the IETF on-line IPR 698 repository at http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention 701 any copyrights, patents or patent applications, or other 702 proprietary rights that may cover technology that may be 703 required to implement this standard. Please address the 704 information to the IETF at ietf-ipr@ietf.org. 706 8. References 708 8.1 Normative References 710 [L1VPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service 711 Requirements for Optical Virtual Private Networks", work in 712 progress. 714 [GMPLS-OVERLAY] Swallow, G., et al., "Generalized Multiprotocol 715 Label Switching(GMPLS)User-Network Interface (UNI): Resource 716 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 717 for the Overlay Model", work in progress. 719 8.2 Informative References 721 [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS - 722 Signaling Functional Description", January 2003, RFC3471. 724 [GMPLS-RSVP-TE] Berger, L. (editor), "Generalized MPLS 725 Signaling - RSVP-TE Extensions", RFC3473, January 2003. 727 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions 728 in Support of Generalized MPLS", work in progress 730 [GMPLS-HIERARCHY] Kompella, K., Rekhter, Y., "LSP Hierarchy 731 with Generalized MPLS TE", work in progress. 733 [GMPLS-ARCH] Mannie, E. (Editor), "Generalized Multi-protocol 734 Label Switching Architecture," RFC3945, October 2004. 736 [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link 737 Bundling in MPLS Traffic Engineering", work in progress. 739 [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, 740 Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3 741 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt, 742 work in progress 744 [GMPLS-LMP] J.P.Lang (Editor), "Link Management Protocol," 745 draft-ietf-ccamp-lmp-10.txt, October 2003. 747 [NSAP-IPV6] Carpenter, B. et al., "OSI NSAPs and IPv6", RFC 748 1888, August 1996. 750 [L3VPN-REQ] A. Nagarajan, "Generic Requirements for Provider 751 Provisioned Virtual Private Networks (PPVPN)" RFC 3809, June 752 2004. 754 9. Acknowledgments 756 The authors would like to thank Adrian Farrel, Hamid Ould- 757 Brahim for their valuable comments. 759 9. Author's Addresses 761 Don Fedyk 762 Nortel Networks 763 600 Technology Park 764 Billerica, Massachusetts 765 01821 U.S.A 766 Phone: +1 (978) 288 3041 767 Email: dwfedyk2nortelnetworks.com 769 Yakov Rekhter 770 Juniper Networks 771 1194 N. Mathilda Avenue 772 Sunnyvale, CA 94089 773 Email: yakov@juniper.net 775 Dimitri Papadimitriou (Alcatel) 776 Fr. Wellesplein 1, 777 B-2018 Antwerpen, Belgium 778 Phone: +32 3 240-8491 779 Email: dimitri.papadimitriou@alcatel.be 781 Richard Rabbat 782 Fujitsu 783 1240 East Arques Ave, MS 345 784 Sunnyvale, CA 94085 785 Email: richard@us.fujitsu.com 787 Lou Berger 788 Movaz Networks, Inc. 789 7926 Jones Branch Drive 790 Suite 615 791 McLean VA, 22102 792 Phone: +1 703 847-1801 793 Email: lberger@movaz.com 795 10. Disclaimer of Validity 797 This document and the information contained herein are provided 798 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 799 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 800 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 801 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 802 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 803 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 804 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 11. Full Copyright Statement 808 Copyright (C) The Internet Society (2005). This document is 809 subject to the rights, licenses and restrictions contained in 810 BCP 78, and 811 except as set forth therein, the authors retain all their 812 rights.