idnits 2.17.1 draft-ietf-l1vpn-basic-mode-05.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 942. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group D. Fedyk(ed.) 3 Internet Draft Nortel 4 Date Created: May 23, 2008 Y Rekhter(ed.) 5 Expiration Date: November 23, 2008 Juniper Networks 6 Intended Status: Standards Track D. Papadimitriou 7 Alcatel-Lucent 8 R. Rabbat 9 Google 10 L. Berger 11 LabN 13 Layer 1 VPN Basic Mode 14 draft-ietf-l1vpn-basic-mode-05.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM). 46 L1VPN Basic mode is a port-based VPN. In L1VPN Basic Mode (BM), the 47 basic unit of service is a Label Switched Path (LSP) between a pair 48 of customer ports within a given VPN port-topology. This document 49 defines the operational model using either provisioning or a VPN 50 auto-discovery mechanism, and the signaling extensions for the L1VPN 51 BM. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 This document expects that the reader is familiar with the 60 terminology defined and used in [RFC3945], [RFC3471], [RFC3473], 61 [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208] and referenced 62 therein. 64 Table of Contents 66 1. Introduction...............................................4 67 2. Layer 1 VPN Service........................................5 68 3. Addressing, Ports, Links and Control Channels..............7 69 3.1 Service Provider Realm....................................7 70 3.2 Layer 1 Ports and Index...................................8 71 3.3 Port and Index Mapping....................................8 72 4. Port Based L1VPN Basic Mode...............................10 73 4.1 L1VPN Port Information Tables............................11 74 4.1.1. Local Auto-Discovery Information......................12 75 4.1.2. PE Remote Auto-Discovery Information..................12 76 4.2 CE to CE LSP Establishment...............................14 77 4.3 Signaling................................................14 78 4.3.1 Signaling Procedures...................................15 79 4.3.1.1 Shuffling Sessions...................................16 80 4.3.1.2 Stitched or Nested Sessions..........................17 81 4.3.1.3 Other Signaling......................................17 82 4.4 Recovery Procedures......................................18 83 5. Security Considerations...................................19 84 6. IANA Considerations.......................................20 85 7. Intellectual Property Considerations......................20 86 8. References................................................21 87 8.1 Normative References.....................................21 88 8.2 Informative References...................................21 89 9. Acknowledgments...........................................23 90 10. Authors' Addresses.......................................23 91 11. Disclaimer of Validity...................................23 92 12. Copyright Statement......................................24 94 1. Introduction 96 This document describes the basic mode of Layer 1 VPNs (L1VPN BM) 97 that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is 98 covered in [L1VPN-APPLIC]. In this document, we consider a layer 1 99 service provider network that consists of devices that support GMPLS 100 (e.g., Lambda Switch Capable devices, Optical Cross Connects, 101 SONET/SDH Cross Connects, etc.). We partition these devices into P 102 (provider) and PE (provider edge) devices. In the context of this 103 document we will refer to the former devices as just "P", and to the 104 latter devices as just "PE". The Ps are connected only to the 105 devices within the provider's network. The PEs are connected to the 106 other devices within the network (either Ps or PEs), as well as to 107 the devices outside of the service provider network. We'll refer to 108 such other devices as Customer Edge (CE) devices. An example of a CE 109 would be a GMPLS-enabled device that is either a router, an SDH 110 cross-connect, or an Ethernet switch. 112 [RFC4208] defines signaling from the CE to the PE. In the [RFC4208], 113 the term Core Node (CN) corresponds to P and PE Nodes, edge Core 114 Node corresponds to PE, and Edge Node (EN) corresponds to CE. 116 Figure 1 illustrates the components in an L1VPN network. 118 +---+ +---+ 119 | P |....| P | 120 +---+ +---+ 121 / \ 122 +-----+ +-----+ +--+ 123 +--+ | PE | | |----| | 124 |CE|----| | | | |CE| 125 +--+\ +-----+ | |----| | 126 \ | | PE | +--+ 127 \ +-----+ | | 128 \| PE | | | +--+ 129 | | | |----|CE| 130 +-----+ +-----+ +--+ 131 \ / 132 +---+ +---+ 133 | P |....| P | 134 +---+ +---+ 136 Figure 1: Generalized Layer 1 VPN Reference Model 138 This document specifies how the L1VPN Basic Mode (BM) service can be 139 realized using off-line provisioning or VPN auto-discovery, 140 Generalized Multi-Protocol Label Switching (GMPLS) Signaling 141 [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] 142 mechanisms. 144 L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN 145 auto-discovery. As with L3VPNs, there are protocol choices to be 146 made with auto-discovery. Section 4.1.1 deals with the information 147 that needs to be discovered. 149 GMPLS routing and signaling are used without extensions within the 150 service provider network to establish and maintain Lambda Switch 151 Capable (LSC) or SONET/SDH (TDM) connections between service 152 provider nodes. This follows the model in [RFC4208]. 154 In L1VPN Basic Mode (BM), the use of LMP facilitates the population 155 of the service provider port information tables. Indeed, LMP MAY be 156 used as an option to automate local CE-PE link discovery. LMP also 157 MAY augment routing in extended mode as well as failure handling 158 capabilities. 160 Consideration of inter-AS and inter-provider L1VPNs requires further 161 analysis beyond the scope of this document. 163 2. Layer 1 VPN Service 165 Layer 1 VPN (L1VPN) services on the interfaces of customer and 166 service provider ports MAY be any of the Layer 1 interfaces 167 supported by GMPLS. Since the mechanisms specified in this document 168 use GMPLS as the signaling mechanism, and since GMPLS applies to 169 both SONET/SDH (TDM) and Lambda Switch Capable (LSC) interfaces, it 170 follows that L1VPN services include (but are not restricted) to 171 Lambda Switch Capable or TDM-based equipment. Note that this 172 document describes Basic Mode L1VPNs and as such requires that: 173 (1) GMPLS RSVP-TE is used for signaling both within the service 174 provider (between PEs), as well as between the customer and the 175 service provider (between CE and PE); 176 (2) GMPLS Routing on the CE-PE link is outside the scope of the 177 basic mode of operation of L1VPN see [RFC4847]. 179 A CE is connected to a PE via one or more links. In the context of 180 this document a link is a GMPLS Traffic Engineering (TE) link 181 construct, as defined in [RFC4202]. In the context of this document, 182 a TE link is a logical construct that is a member of a VPN hence 183 introducing the notion of membership to a set of CEs forming the 184 VPN. Interfaces at the end of each link are limited to type LSC or 185 TDM that are supported by GMPLS. More specifically a link 186 MUST be of the type or where X = PSC, L2SC or TDM 187 and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X 188 MAY also = LSC and Y = TDM. One of the applications of a L1VPN 189 connection is to provide a "virtual private lambda" or similar. In 190 this case, the CE is truly the end point in GMPLS terms and its 191 switching capability on the TE link is not relevant (although its 192 GPID MUST be signaled and identical at both CEs i.e. head-end and 193 tail-end CE). ) 194 Likewise, PEs could be any Layer 1 devices that are supported by 195 GMPLS (e.g., optical cross connects, SDH cross-connects), while CEs 196 MAY be devices at layers 1, 2 and 3 such as an SDH cross-connect, an 197 Ethernet switch, and a router respectively). 199 Each TE link MAY consist of one or more channels or sub-channels 200 (e.g., wavelength or wavelength and timeslot respectively). For the 201 purpose of this discussion all the channels within a given link MUST 202 have similar shared characteristics (e.g., switching capability, 203 encoding, type, etc.), and MAY be selected independently from the 204 CE's point of view. Channels on different links of a CE need not 205 have the same characteristics. 207 There MAY be more than one TE link between a given CE-PE pair. A CE 208 MAY be connected to more than one PE (with at least one port per 209 PE). And, conversely, a PE MAY have more than one CE from different 210 VPNs connected to it. 212 If a CE is connected to a PE via multiple TE links and all the links 213 belong to the same VPN, these links (referred to as component links) 214 MAY be treated as a single TE link using the link bundling 215 constructs [RFC4201]. 217 In order to satisfy the requirements of the L1VPN Basic Mode it is 218 REQUIRED that for a given CE-PE pair at least one of the links 219 between them has at least one data bearing channel, and at least one 220 control bearing channel, or there is IP reachability between the CE 221 and the PE that could be used to exchange control information. 223 A point-to-point link has two end-points - one on the CE and one on 224 the PE. This document refers to the former as "CE port", and to the 225 latter as "PE port". From the above it follows that a CE is 226 connected to a PE via one or more ports, where each port MAY consist 227 of one or more channels or sub-channels (e.g., wavelength or 228 wavelength and timeslot respectively), and all the channels within a 229 given port have shared similar characteristics and can be 230 interchanged from the CE's point of view. Similar to the definition 231 of a TE link, in the context of this document, ports are logical 232 constructs that are used to represent a grouping of physical 233 resources that are used to connect a CE to a PE on a per L1VPN 234 basis. 236 At any point in time, a given port on a PE is associated with at 237 most one L1VPN, or to be more precise with at most one Port 238 Information Table maintained by the PE (although different ports on 239 a given PE could be associated with different L1VPNs, or to be more 240 precise with different Port Information Tables). The association of 241 a port with a VPN MAY be defined by provisioning the relationship on 242 the service provider devices. In other words the context of a VPN 243 membership in Basic mode is enforced through service provider 244 control. 246 It is REQUIRED that the interface between the CE and PE used for the 247 purpose of signaling be capable of initiating/processing GMPLS 248 protocol messages [RFC3473] and follow the procedures described in 249 [RFC4208]. 251 An important goal of L1VPN service is the ability to support what is 252 known as "single-ended provisioning", where the addition of a new 253 port to a given L1VPN involves configuration changes only on the PE 254 that has this port. The extension of this model to the CE is 255 outside the scope of the L1VPN BM. 257 Another important goal in the L1VPN service is the ability to 258 establish/terminate an LSP between a pair of (existing) ports within 259 an L1VPN from the CE devices without involving configuration changes 260 in any of the service provider's devices. In other words, the VPN 261 topology is under the CE device control (provided that the 262 underlying PE-PE connectivity be provided and allowed by the 263 network). 265 The mechanisms outlined in this document aim to achieve these above 266 goals. Specifically, as part of the L1VPN service offering, these 267 mechanisms (1) enable the service provider to restrict the set of 268 ports to which a given port could be connected, (2) enable a CE to 269 establish the actual LSP to a subset of ports. Finally, the 270 mechanisms allow arbitrary L1VPN topologies to be supported ranging 271 from hub-and-spoke to full mesh point-to-point connections. Only 272 point-to-point links are supported. 274 The exchange of CE routing or topology information to the service 275 provider is out of scope for L1VPN BM mode. 277 3. Addressing, Ports, Links and Control Channels 279 GMPLS-established conventions for addressing and link numbering are 280 discussed in [RFC3945]. This section builds on those definitions 281 for the L1VPN case where we now have customer and service provider 282 addresses in a Layer 1 context. 284 3.1 Service Provider Realm 286 It is REQUIRED that a service provider, or a group of service 287 providers that collectively offer L1VPN service, have a single 288 addressing realm that spans all PE devices involved in providing the 289 L1VPN service. This is necessary to enable GMPLS mechanisms for path 290 establishment and maintenance. We will refer to this realm as the 291 service provider addressing realm. It is further REQUIRED that each 292 L1VPN customer have its own addressing realm with complete freedom 293 to use private or public addresses. We will refer to such realms as 294 the customer addressing realms. Customer addressing realms MAY 295 overlap addresses (i.e. non unique address) with each other, and MAY 296 also overlap addresses with the service provider realm. 298 3.2 Layer 1 Ports and Index 300 Within a given L1VPN, each port on a CE that connects the CE to a PE 301 has an identifier that is unique within that L1VPN (but need not be 302 unique across several L1VPNs). One way to construct such an 303 identifier is to assign each port an address that is unique within a 304 given L1VPN, and use this address as a port identifier. Another way 305 to construct such an identifier is to assign each port on a CE an 306 index that is unique within that CE, assign each CE an address that 307 is unique within a given L1VPN, and then use a tuple as a port identifier. Note that both the port and the CE 309 address MAY be an address in several formats. This includes, but is 310 not limited to IPv4, and IPv6. This identifier is part of the 311 Customer addressing Realm and is used by the CE device to identify 312 the CE port and the CE remote port for signaling. CEs do not know 313 or understand the service provider Realm addresses. 315 Within a service provider network, each port on a PE that connects 316 that PE to a CE has an identifier that is unique within that 317 network. One way to construct such an identifier is to assign each 318 port on a PE an index that is unique within that PE, assign each PE 319 an IP address that is unique within the service provider addressing 320 realm, and then use a tuple or as a port identifier within the service 322 provider network. Another way to construct such an identifier is to 323 assign an IPv4 or IPv6 address that is unique within the service 324 provider addressing realm to each such port. Either way, this IPv4 325 or IPv6 address is internal to the service provider network and is 326 used for GMPLS signaling within the service provider network. 328 As a result, each link connecting the CE to the PE is associated 329 with a CE port that has a unique identifier within a given L1VPN, 330 and with a PE port that has a unique identifier within the service 331 provider network. We'll refer to the former as the customer Port 332 Identifier (CPI), and to the latter as the Provider Port Identifier 333 (PPI). 335 3.3 Port and Index Mapping 337 This document requires that each PE port that has a PPI also has an 338 identifier that is unique within the L1VPN customer addressing realm 339 of the L1VPN associated with that port. One way to construct such 340 an identifier is to assign each port an address that is unique 341 within a given L1VPN customer addressing realm, and use this address 342 as a port identifier. Another way to construct such an identifier is 343 to assign each port an index that is unique within a given PE, 344 assign each PE an IP address that is unique within a given L1VPN 345 customer addressing realm (but need not be unique within the service 346 provider network), and then use a tuple 347 that acts as a port identifier. We'll refer to such port identifier 348 as the VPN-PPI. See Figure 2. 350 For L1VPNs it is a requirement that service provider operations are 351 independent of the VPN customer's addressing realm and the service 352 provider addressing realm is hidden from the customer. To achieve 353 this we have created two identifiers at the PE, one customer facing 354 and the other service provider facing. The PE IP address used for 355 the VPN-PPI is independent of the PE IP address used for the PPI (as 356 the two are taken from different address realms, the former from the 357 customer's addressing realm and the latter from a VPN service 358 Provider's addressing realm). If for a given port on a PE, the PPI 359 and the VPN-PPI port identifiers are unnumbered, then they both 360 could use exactly the same port index. This is a mere convenience 361 since the PPI and VPN_PPI can be in any combination of valid 362 formats. 364 (Customer realm) 365 +----+ +----+ 366 | | | | 367 | |CPI VPN-PPI | | 368 ---| CE |-----------------------------| PE |--- 369 | | | | 370 | | PPI | | 371 +----+ +----+ 372 (Provider realm) 374 Figure 2: Customer/Provider Port/Index Mapping 376 Note, as stated earlier, that IP addresses used for the CPIs, PPIs 377 and VPN-PPIs could be either IPv4, or IPv6 format addresses. 379 For a given link connecting a CE to a PE: 381 - If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 382 address as well since VPN-PPI are created from the customer address 383 space. If the CPI is a , then the 384 VPN-PPI MUST be a for the same reason. 386 - If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 387 address as well since VPN-PPI are created from the customer address 388 space. If the CPI is a , then the 389 VPN-PPI MUST be a for the same reason. 391 Note: for a given port on PE, whether the VPN-PPI of that port is an 392 IP address or a is independent of the 393 format of the PPI of that port. 395 This document assumes that assignment of the PPIs is controlled 396 solely by the service provider (without any coordination with the 397 L1VPN customers), while assignment of addresses used by the CPIs and 398 VPN-PPIs is controlled solely by the administrators of L1VPN. This 399 provides maximum flexibility. The L1VPN administrator is the entity 400 that controls the L1VPN service specifics for the L1VPN customers. 401 This function may be owned by the service provider but may also be 402 performed by a third party who has agreements with the service 403 provider. And, of course, each L1VPN customer could assign such 404 addresses on its own, without any coordination with other L1VPNs. 406 This document also requires IP connectivity between the CE and the 407 PE as specified earlier, which is used for the control channel 408 between CE and PE. This connectivity could be either a single IP 409 hop, which could be realized by either a dedicated link or by an L2 410 VPN, or an IP private network, such as L3VPN. The only requirement 411 on this connectivity is an unambiguous way to correlate a particular 412 CE-PE control channel with a particular L1VPN. When such a channel 413 is realized by a dedicated link, such a link should be associated 414 with a particular L1VPN. When such channel is realized by an L2VPN, 415 a distinct L2VPN should be associated with an L1VPN. When such 416 channel is realized by an L3VPN, a distinct L3VPN should be 417 associated with an L1VPN. 419 We'll refer to the CE's address of this channel as the CE Control 420 Channel Address (CE-CC-Addr), and to the PE's address of this 421 channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC- 422 Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they 423 belong to, but are not REQUIRED to be unique across multiple L1VPNs. 424 Control channel addresses are not shared amongst multiple VPNs. 425 Assignment of CE-CC-Addr and PE-CC-Addr is controlled by the 426 administrators of the L1VPN. 428 Multiple ports on a CE could share the same control channel only as 429 long as all these ports belong to the same L1VPN. Likewise, multiple 430 ports on a PE could share the same control channel only as long as 431 all these ports belong to the same L1VPN. 433 4. Port Based L1VPN Basic Mode 435 An L1VPN is a port-based VPN service where a pair of CEs could be 436 connected through the service provider network via a GMPLS-based LSP 437 within a given VPN port topology. It is precisely this LSP that 438 forms the basic unit of the L1VPN service that the service provider 439 network offers. If a port by which a CE is connected to a PE 440 consists of multiple channels (e.g., multiple wavelengths), the CE 441 could establish LSPs to multiple other CEs in the same VPN over this 442 single port. 444 In the L1VPN, the service provider does not initiate the creation of 445 an LSP between a pair of CE ports. The LSP establishment is 446 initiated by the CE. However, the SP, by using the 447 mechanisms/toolkit outlined in this document, restricts the set of 448 other CE ports, which may be the remote endpoints of LSPs that have 449 the given port as the local endpoint. Subject to these restrictions, 450 the CE-to-CE connectivity is under the control of the CEs 451 themselves. In other words, the SP allows a L1VPN to have a certain 452 set of topologies (expressed as a port-to-port connectivity matrix. 453 CE-initiated signaling is used to choose a particular topology from 454 that set. 456 For each L1VPN that has at least one port on a given PE, the PE 457 maintains a Port Information Table (PIT) associated with that L1VPN. 458 This tables contains a list of tuples for all the ports 459 within its L1VPN. In addition, for local PE ports of a given L1VPN 460 the tuples also include the VPN-PPIs of these ports. 462 PE PE 463 +---------+ +--------------+ 464 +--------+ | +------+| | +----------+ | +--------+ 465 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 466 | CE1 |--| |PIT || Route | | PIT | |-| CE2 | 467 +--------+ | | ||<----------->| | | | +--------+ 468 | +------+|Dissemination| +----------+ | 469 | | | | 470 +--------+ | +------+| | +----------+ | +--------+ 471 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 472 | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 | 473 +--------+ | | || (Backbone ) | | | | +--------+ 474 | +------+| --------- | +----------+ | 475 | | | | 476 +--------+ | +-----+ | | +----------+ | +--------+ 477 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 478 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 479 +--------+ | | | | | | | | +--------+ 480 | +-----+ | | +----------+ | 481 +---------+ +--------------+ 483 Figure 3 Basic Mode L1VPN Service 485 4.1 L1VPN Port Information Tables 487 Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C with their 488 associated PITs. A PIT consists of local information as well as 489 remote information. It follows that PIT on a given PE is populated 490 from two information sources: 492 1. The information related to the CEs' ports attached to the ports 493 local to that PE. 494 2. The information about the CEs connected to the remote PEs 496 A PIT MAY be populated via provisioning or by auto-discovery 497 procedures. When provisioning is used the entire table MAY be 498 populated by provisioning commands either at a console or by a 499 management system which may have some automation capability. 500 As the network grows some form of automation is desirable. 502 For local information between a CE and a PE, a PE MAY leverage LMP 503 to populate the link information. This local 504 information also needs to be propagated to other PEs that share the 505 same VPN. The mechanisms for this are out of scope for this document 506 but the information needed to be exchanged is described in section 507 4.1.1. 509 The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a 510 PIT for each L1VPN for which it has member CEs locally attached. A 511 PE is does not need to maintain PITs for other L1VPNs. However, the 512 full set of PITs with all L1VPN entries for multiple VPNs MAY also 513 be available to all PEs. 515 The remote information in the context of a VPN identifier (i.e., the 516 remote CEs of this VPN) MAY also be sent to the local CE belonging 517 to the same VPN. Exchange of this information is outside the scope 518 of this document. 520 4.1.1. Local Auto-Discovery Information 522 The information that needs to be discovered on a PE local port is 523 the local CPI and the VPN-PPI. 525 This information MAY be configured or if LMP is used between the CE 526 and PE, LMP MAY be used to exchange this information. 528 Once a CPI has been discovered, the corresponding VPN-PPI maps in a 529 local context to a VPN Identifier and a corresponding PPI. 530 One way to enforce a provider controlled VPN context is to pre- 531 provision VPN-PPI's with a VPN identifier. Other policy mechanisms 532 to achieve this are outside the scope of this document. In this 533 manner, a relationship of a CPI to a VPN and PPI port can be 534 established when the port is provisioned as belonging to the VPN. 536 4.1.2. PE Remote Auto-Discovery Information 538 This section provides the information that is carried by any auto- 539 discovery mechanism, and is used to dynamically populate a PIT. The 540 information provides a single mapping. Each auto- 541 discovery mechanism will define the method(s) by which multiple 542 mappings are communicated, as well as invalidated. 544 This information should be consistent regardless of the mechanism 545 used to distribute the information [L1VPN-BGP-AD], [L1VPN-OSPF-AD]. 547 The format of encoding a single tuple is: 549 +---------------------------------------+ 550 | PPI Length (1 octet) | 551 +---------------------------------------+ 552 | PPI (variable) | 553 +---------------------------------------+ 554 | CPI AFI (2 octets) | 555 +---------------------------------------+ 556 | CPI (length) | 557 +---------------------------------------+ 558 | CPI (variable) | 559 +---------------------------------------+ 561 Figure 4: Auto-Discovery Information 563 The use and meaning of these fields are as follows: 565 PPI Length: 567 A one octet field whose value indicates the length of the PPI 568 field. 570 PPI field: 572 A variable length field that contains the value of the PPI 573 (either an address or tuple. Note, PPI is 574 always encoded consistently within a provider domain so the 575 format of the PPI field is implicit within a given provider 576 network. 578 CPI AFI field: 580 A two octets field whose value indicates address family of the 581 CPI. This value is assigned in [L1VPN-BGP-AD]. 583 CPI Length: 585 A one octet field whose value indicates the length of the CPI 586 field. 588 CPI (variable): 590 A variable length field that contains the CPI value (either an 591 address or tuple. 593 tuples MUST also be associated with one or more globally 594 unique identifiers associated with a particular VPN. A globally 595 unique identifier can encode a VPN-ID, a route target, or any other 596 globally unique identifier. The globally unique identifiers are 597 under control of network providers. Uniqueness within a service 598 provider administrative domain is sufficient for basic mode 599 operation. In the case of multiple provider networks which is beyond 600 the scope of this document, the globally unique identifier need only 601 be unique and consistent between the those providers. In this 602 document we specify a generic encoding format for the globally 603 unique identifier common to all the auto-discovery mechanisms. 604 However, each auto-discovery mechanism will define the specific 605 method(s) by which the encoding is distributed and the association 606 with a tuple is made. The encoding of the globally 607 unique identifier associated with the VPN is: 609 +------------------------------------------------+ 610 | L1vpn Globally unique identifier (8 octets) | 611 +------------------------------------------------+ 613 Figure 5: Auto-Discovery Globally unique identifier Format 615 4.2 CE to CE LSP Establishment 617 In order to establish an LSP, a CE needs to identify all other CEs 618 in the CE's L1VPN it wants to connect to. A CE may already have 619 obtained this information through provisioning or through some other 620 schemes (such schemes are outside the scope of this document). 622 Ports associated with a given CE-PE link, in addition to their CPI 623 and PPI MAY also have other information associated with them that 624 describes characteristics and constraints of the channels within 625 these ports, such as encoding supported by the channels, bandwidth 626 of a channel, total unreserved bandwidth within the port, etc. This 627 information could be further augmented with the information about 628 certain capabilities of the service provider network (e.g., support 629 regeneration section overhead (RSOH) Data Communications Channel 630 (DCC) transparency, arbitrary concatenation, etc.). This information 631 is used to ensure that ports at each end of an LSP have compatible 632 characteristics, and that there are sufficient unallocated resources 633 to establish an LSP between these ports. 635 It may happen that for a given pair of ports within an L1VPN, each 636 of the CEs connected to these ports would concurrently try to 637 establish an LSP to the other CE. If having a pair of LSPs between a 638 pair of ports is viewed as undesirable, the way to resolve this is 639 to require the CE with the lower value of the CPI to terminate the 640 LSP originated by the CE. This option could be controlled by 641 configuration on the CE devices. 643 4.3 Signaling 645 In L1VPN BM a CE needs to be configured with the CPIs of other 646 ports. Once a CE is configured with the CPIs of the other ports 647 within the same L1VPN, which we'll refer to as "target ports", the 648 CE uses a (subset of) GMPLS signaling, to request the provider 649 network to establish an LSP to a target port. 651 For inter-CE connectivity, the request originated by the CE contains 652 the CPI of the port on the CE that CE wants to use for the LSP, and 653 the CPI of the target port. When the PE attached to the CE that 654 originated the request receives the request, the PE identifies the 655 appropriate PIT, and then uses the information in that PIT to find 656 out the PPI associated with the CPI of the target port carried in 657 the request. The PPI should be sufficient for the PE to establish an 658 LSP. Ultimately the request reaches the CE associated with the 659 target CPI (note that the request still carries the CPI of the CE 660 that originated the request). If the CE associated with the target 661 CPI accepts the request, the LSP is established. 663 Note that a CE need not establish an LSP to every target port that 664 CE knows about - it is a local CE matter to select a subset of 665 target ports to which the CE will try to establish LSPs. 667 The procedures for establishing an individual connection between two 668 corresponding CEs is the same as the procedure specified for GMPLS 669 overlay [RFC4208]. 671 4.3.1 Signaling Procedures 673 When an ingress CE sends an RSVP Path message to an ingress PE, the 674 source IP address in the IP packet that carries the message is set 675 to the appropriate CE-CC-Addr, and the destination IP address in the 676 packet is set to the appropriate PE-CC-Addr. When the ingress PE 677 sends back to the ingress CE the corresponding Resv message, the 678 source IP address in the IP packet that carries the message is set 679 to the PE-CC-Addr, and the destination IP address is set to the CE- 680 CC-Addr. 682 Likewise, when an egress PE sends an RSVP Path message to an egress 683 CE, the source IP address in the IP packet that carries the message 684 is set to the appropriate PE-CC-Addr, and the destination IP address 685 in the packet is set to the appropriate CE-CC-Addr. When the egress 686 CE sends back to the egress PE the corresponding Resv message, the 687 source IP address in the IP packet that carries the message is set 688 to the CE-CC-Addr, and the destination IP address is set to the PE- 689 CC-Addr. 691 In addition to being used for IP addresses in the IP packet that 692 carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr 693 are also used in the Next/Previous Hop Address field of the IF_ID 694 RSVP_Hop Object that is carried between CEs and PEs. 696 In the case where a link between CE and PE is a numbered non-bundled 697 link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 698 TLVs of the IF_ID RSVP Hop Object that is carried between the CE and 699 PE. In the case where a link between CE and PE is an unnumbered non- 700 bundled link, the CPI and VPN-PPI of that link are used for the IP 701 Address field of the Type 3 TLV. In the case where a link between CE 702 and PE is a bundled link, the CPI and VPN-PPI of that link are used 703 for the IP Address field of the Type 3 TLVs. 705 Additional processing related to unnumbered links is described in 706 the "Processing the IF_ID RSVP_Hop Object"/"Processing the IF_ID 707 TLV", and "Unnumbered Forwarding Adjacencies" sections of RFC 3477 708 [RFC3477]. 710 When an ingress CE originates a Path message to establish an LSP 711 from a particular port on that CE to a particular target port, the 712 CE uses the CPI of its port in the Sender Template object. If the 713 CPI of the target port is an IP address, then the CE uses it in the 714 Session object. And if the CPI of the target port is a tuple, then the CE uses the IP address part of the tuple 716 in the Session object, and the whole tuple as the Unnumbered 717 Interface ID subobject in the ERO. 719 There are two options for RSVP-TE sessions. One option is to have a 720 single RSVP-TE session end to end where the addresses of the 721 customer and the provider are swapped at the PE, termed shuffling. 722 The other option is when stitching or hierarchy is used to create 723 two LSP sessions, one between the provider PE(s) and another end to 724 end session between the CEs. 726 4.3.1.1 Shuffling Sessions 728 Shuffling sessions are used when the desire is to have a single LSP 729 originating at the CE and terminating at the far end CE. The 730 customer addresses are shuffled to provider addresses at the ingress 731 PE, and back to customer addresses at the egress PE by using the 732 mapping provided by the PIT. 734 When the Path message arrives at the ingress PE, the PE selects the 735 PIT associated with the L1VPN, and then uses this PIT to map CPIs 736 carried in the Session and the Sender Template objects to the 737 appropriate PPIs. Once the mapping is done, the ingress PE replaces 738 CPIs with these PPIs. As a result, the Session and the Sender 739 Template objects that are carried in the GMPLS signaling within the 740 service provider network carry PPIs, and not CPIs. 742 At the egress PE, the reverse mapping operation is performed. The PE 743 extracts the ingress/egress PPI values carried in the Sender 744 Template and Session objects (respectively). The egress PE 745 identifies the appropriate PIT to find the appropriate CPI 746 associated with the PPI of the egress CE. Once the mapping is 747 retrieved, the egress PE replaces the ingress/egress PPI values with 748 the corresponding CPI values. As a result, the Session and the 749 Sender Template objects included in the GMPLS RSVP-TE Path message 750 sent from the egress PE to the egress CE carry CPIs, and not PPIs. 752 Here also, for the GMPLS RSVP-TE Path messages sent from the egress 753 PE to CE, the source IP address (of the IP packet carrying this 754 message) is set to the appropriate PE-CC-Addr, and the destination 755 IP address (of the IP packet carrying this message) is set to the 756 appropriate CE-CC-Addr. 758 At this point the CE's view is a single LSP point to point between 759 the two CEs with a virtual link between the PE nodes. CE-PE(-)PE- 760 CE. The L1VPN PE nodes have a view of the PE-PE LSP segment in all 761 its detail. The PEs MAY filter the RSVP-TE signaling removing 762 information about the provider topology and replacing it with a view 763 of a virtual link. 765 This translation of addresses and session ids is termed shuffling 766 and driven by the L1VPN Port information tables (see section 4). 767 This MUST be performed for all RSVP-TE Messages at the PE edges. In 768 this case there is one CE to CE session. 770 4.3.1.2 Stitched or Nested Sessions 772 Stitching or Nesting options are dependent on the LSP switching 773 types. If the CE to CE and PE to PE LSPs are identical in switching 774 type and capacity the LSP MAY be stitched together and the 775 procedures in [RFC5150] apply. If the CE to CE LSPs and the PE to PE 776 LSPs are of not the same switching type or of different but 777 compatible capacity the LSPs MAY be Nested and the procedures for 778 [RFC4206] apply. The Stitched and Nested LSP signaling are 779 analogous procedures and can be discussed together. 781 When the Path Message arrives at the ingress PE, the PE selects the 782 PIT associated with the L1VPN, and then uses this PIT to map CPIs 783 carried in the Session and the Sender Template objects to the 784 appropriate PPIs. Once the mapping is done, a new PE to PE session 785 is established with the parameters compatible with the CE session. 786 Upon successful establishment of the PE to PE session, the CE 787 signaling request is sent to the egress PE. 789 At the ingress PE, when stitching and nesting are used a PE to PE 790 session is established. This could be achieved by several means: 791 - Associating an already established PE-PE FA-LSP or LSP to the 792 destination that meets the requested parameters. 793 - Establishing a compliant PE-PE LSP segment. 795 At this point the CE's view is a single LSP point to point between 796 the two CEs with a virtual node between the PE nodes. CE-PE(-)PE- 797 CE. The L1VPN PE nodes have a view of the PE-PE LSP segment in all 798 its detail. The PEs do not have to filter the RSVP-TE signaling 799 removing information about the provider topology because the PE-PE 800 signaling is not visible to the CE nodes. 802 4.3.1.3 Other Signaling 803 An ingress PE may receive and potentially reject a Path message that 804 contains an Explicit Route Object and so cause the switched 805 connection setup to fail. However, the ingress PE may accept EROs, 806 which include a sequence of {}. 809 - Path message without ERO: when an ingress PE receives a Path 810 message from an ingress CE that contains no ERO, it MUST calculate a 811 route to the destination for the PE-to-PE LSP and include that route 812 in an ERO, before forwarding the Path message. One exception would 813 be if the egress core node were also adjacent to this core node. 815 - Path message with ERO: when an ingress PE receives a Path message 816 from an ingress CE that contains an ERO (of the form detailed 817 above), the former computes a path to reach the egress PE. It then 818 inserts this path as part of the ERO before forwarding the Path 819 message. 821 In the case of Shuffling the overlay rules for Notification and RRO 822 Processing are identical to the UNI or Overlay Model[RFC4208] which 823 state that Edge PE MAY remove/edit Provider Notification and RRO 824 objects when passing the messages to the CEs. 826 4.4 Recovery Procedures 828 Signaling: 830 A CE requests a network protected (from PE-to-PE) LSP by using 831 [RFC4873] technique. Dynamic identification of merge nodes is 832 supported via the LSP Segment Recovery Flags carried in the 833 Protection object (see Section 6.2 of [RFC4873]). 835 Notification: 837 A Notify Request object MAY be inserted in Path or Resv messages to 838 indicate the address of a CE that should be notified of an LSP 839 failure. Notifications MAY be requested in both the upstream and 840 downstream directions: 842 o) Upstream notification is indicated via the inclusion of a Notify 843 Request object in the corresponding Path message. 845 o) Downstream notification is indicated via the inclusion of a 846 Notify Request object in the corresponding Resv message. 848 A PE receiving a message containing a Notify Request object SHOULD 849 store the Notify Node Address in the corresponding RSVP state block. 850 The PE SHOULD also include a Notify Request object in the outgoing 851 Path or Resv message. The outgoing Notify Node Address MAY be 852 updated based on local policy. This means that a PE upon reception 853 of this object from the CE MAY update its value. 855 If the ingress CE includes a Notify Request object into the Path 856 message, the ingress PE MAY replace the received 'Notify Node 857 Address' by its own selected 'Notify Node Address', and in 858 particular the local TE Router_ID. The Notify Request object MAY be 859 carried in Path or Resv messages (Section 7 of [RFC3473]). The 860 format of the Notify Request object is defined in [RFC3473]. 861 In GMPLS, Notify Node Addresses may be IPv4 or IPv6 [RFC3473]. 863 Inclusion of a Notify Request object is used to request the 864 generation of notifications upon failure occurrence but does not 865 guarantee that a Notify message will be generated. 867 5. Security Considerations 869 Security for L1VPNs is covered in [RFC4847] and [L1VPN-APPLIC]. In 870 this document we discuss the security aspects with respect to the 871 control plane. 873 The association of a particular port with a particular L1VPN (or to 874 be more precise with a particular PIT) is a configuration operation, 875 generally done manually by the service provider as part of the 876 service provisioning process. Thus, it cannot be altered via 877 signaling between CE and PE. This means that the signaling cannot be 878 used to deliver L1VPN traffic to the wrong customer. The operator 879 should apply appropriate security mechanisms to the management and 880 configuration process, and should consider data plane verification 881 techniques to protect against accidental misconfiguration. The 882 customer may also apply end-to-end (i.e., CE to CE) data plane 883 connectivity tests over the L1VPN connection to detect 884 misconnection. Data plane connectivity testing can be performed 885 using the Link Management Protocol (LMP) [RFC4204]. 887 Note that it is also possible to populate the local part of a PIT 888 using autodiscovery through LMP. LMP may be secured as described in 889 [RFC4204]. Signaling between CE and PE is assumed to be over a 890 private link (for example, in-band or in-fiber) or a private 891 network. Use of a private link makes the CE-PE connection secure at 892 the same level as the data link described in the previous 893 paragraphs. The use of a private network assumes that entities 894 outside the network cannot spoof or modify control plane 895 communications between CE and PE. Furthermore, all entities in the 896 private network are assumed to be trusted. Thus, no security 897 mechanisms are required by the protocol exchanges described in this 898 document. 900 However, an operator that is concerned about the security of their 901 private control plane network may use the authentication and 902 integrity functions available in RSVP-TE [RFC3473] or utilize IPsec 903 [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411] for the 904 point-to-point signaling between PE and CE. See [MPLS-SEC] for a 905 full discussion of the security options available for the GMPLS 906 control plane. 908 Note further that a private network (e.g., Layer 2 VPN, or Layer 3 909 VPN) might be used to provide control plane connectivity between a 910 PE and more than one CE. In this scenario, it is RECOMMENDED that 911 each L1 VPN customer would have its own such private network. Then 912 the security mechanisms provided by the private network SHOULD be 913 used to ensure security of the control plane communication between a 914 customer and a service provider. 916 6. IANA Considerations 918 This document makes no requests for IANA action. 920 7. Intellectual Property Considerations 922 The IETF takes no position regarding the validity or scope of any 923 Intellectual Property Rights or other rights that might be claimed 924 to pertain to the implementation or use of the technology described 925 in this document or the extent to which any license under such 926 rights might or might not be available; nor does it represent that 927 it has made any independent effort to identify any such rights. 928 Information on the procedures with respect to rights in RFC 929 documents can be found in BCP 78 and BCP 79. 931 Copies of IPR disclosures made to the IETF Secretariat and any 932 assurances of licenses to be made available, or the result of an 933 attempt made to obtain a general license or permission for the use 934 of such proprietary rights by implementers or users of this 935 specification can be obtained from the IETF on-line IPR repository 936 at http://www.ietf.org/ipr. 938 The IETF invites any interested party to bring to its attention any 939 copyrights, patents or patent applications, or other proprietary 940 rights that may cover technology that may be required to implement 941 this standard. Please address the information to the IETF at ietf- 942 ipr@ietf.org. 944 8. References 946 8.1 Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC3471] Berger, L. (editor), "Generalized MPLS -Signaling 952 Functional Description", January 2003, RFC3471. 954 [RFC3473] Berger, L. (editor), "Generalized MPLS Signaling - RSVP-TE 955 Extensions", RFC3473, January 2003. 957 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 958 Links in Resource ReSerVation Protocol - Traffic 959 Engineering (RSVP-TE)", RFC 3477, January 2003. 961 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support 962 of Generalized Multi-Protocol Label Switching (GMPLS)", 963 RFC 4202, October 2005. 965 [RFC4204] J. Lang (editor), "Link Management Protocol (LMP)," RFC 966 4204, October 2005. 968 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 969 Hierarchy with Generalized Multi-Protocol Label Switching 970 (GMPLS)Traffic Engineering (TE)", RFC 4206, October 2005. 972 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 973 Switching (GMPLS) User-Network Interface (UNI): Resource 974 ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 975 for the Overlay Model", RFC 4208, October 2005. 977 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. Farrel, A., 978 "GMPLS Based Segment Recovery", RFC 4873, May 2007. 980 [RFC5150] A. Ayyangar, K. Kompella, J.P. Vasseur, A. Farrel, "Label 981 Switched Path Stitching with Generalized MPLS Traffic 982 Engineering", RFC 5150, February 2008. 984 8.2 Informative References 986 [RFC3945] E. Mannie (editor), "Generalized Multi-Protocol Label 987 Switching (GMPLS) Architecture" RFC3945, October 2004. 989 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 990 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 992 [RFC4847] Takeda, T., Editor "Framework and Requirements for Layer 1 993 Virtual Private Networks", RFC 4847, April 2007. 995 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 996 Roadmap," November 1998. 998 [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet 999 Protocol," December 2005. 1001 [RFC4302] S. Kent, "IP Authentication Header," December 2005. 1003 [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", 1004 December 2005. 1006 [RFC4835] V. Manral, "Cryptographic Algorithm Implementation 1007 Requirements for Encapsulating Security Payload (ESP) and 1008 Authentication Header (AH)", April 2007. 1010 [L1VPN-BGP-AD] Ould-Brahim, H., Fedyk, D., Rekhter, Y., "BGP-based 1011 Auto-Discovery for L1VPNs", work in progress. 1013 [L1VPN-OSPF-AD] Bryskin, I., Berger, Lou "OSPF Based L1VPN Auto- 1014 Discovery", work in progress. 1016 [L1VPN-APPLIC] Takeda, T (editor), "Applicability Statement for 1017 Layer 1 Virtual Private Networks (L1VPNs) Basic Mode", 1018 draft-ietf-l1vpn-applicability-basic-mode, work in 1019 progress. 1021 [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS 1022 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 1023 framework, work in progress. 1025 9. Acknowledgments 1027 The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, 1028 and Tomonori Takeda for their valuable comments. 1030 Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim 1031 Polk, and Ron Bonica provided input during the IESG review process. 1033 10. Authors' Addresses 1035 Don Fedyk 1036 Nortel Networks 1037 600 Technology Park 1038 Billerica, Massachusetts 1039 01821 U.S.A 1040 Phone: +1 (978) 288 3041 1041 Email: dwfedyk@nortel.com 1043 Yakov Rekhter 1044 Juniper Networks 1045 1194 N. Mathilda Avenue 1046 Sunnyvale, CA 94089 1047 Email: yakov@juniper.net 1049 Dimitri Papadimitriou 1050 Alcatel-Lucent 1051 Fr. Wellesplein 1, 1052 B-2018 Antwerpen, Belgium 1053 Phone: +32 3 240-8491 1054 Email: Dimitri.Papadimitriou@alcatel-lucent.be 1056 Richard Rabbat 1057 Google, Inc 1058 1600 Amphitheatre Pkwy 1059 Mountain View, CA 95054 1060 Email: rabbat@alum.mit.edu 1062 Lou Berger 1063 LabN Consulting, LLC 1064 Phone: +1 301-468-9228 1065 EMail: lberger@labn.net 1067 11. Disclaimer of Validity 1069 "This document and the information contained herein are provided on 1070 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1071 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1072 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1073 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1074 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1075 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1076 PARTICULAR PURPOSE. 1078 12. Copyright Statement 1080 Copyright (C) The IETF Trust (2008). 1082 This document is subject to the rights, licenses and restrictions 1083 contained in BCP 78, and except as set forth therein, the authors 1084 retain all their rights.