idnits 2.17.1 draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2010) is 4921 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) ** Obsolete normative reference: RFC 4871 (ref. 'RFC4872') (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Don Fedyk, Alcatel-Lucent 2 Category: Standards Track Himanshu Shah, Force10 Networks 3 Expiration Date: March 28, 2011 Nabil Bitar, Verizon 4 Attila Takacs, Ericsson 6 September 28, 2010 8 Generalized Multiprotocol Label Switching (GMPLS) control of 9 Ethernet Provider Backbone Traffic Engineering (PBB-TE) 11 draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This document may contain material from IETF Documents or IETF 19 Contributions published or made publicly available before November 20 10, 2008. The person(s) controlling the copyright in some of this 21 material may not have granted the IETF Trust the right to allow 22 modifications of such material outside the IETF Standards Process. 23 Without obtaining an adequate license from the person(s) controlling 24 the copyright in such materials, this document may not be modified 25 outside the IETF Standards Process, and derivative works of it may 26 not be created outside the IETF Standards Process, except to format 27 it for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on March 28, 2011. 48 Copyright and License Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Abstract 65 This specification is complementary to the GMPLS Ethernet Label 66 Switching Architecture and Framework and describes the technology 67 specific aspects of GMPLS control for Provider Backbone Bridge 68 Traffic Engineering (PBB-TE). The necessary GMPLS extensions and 69 mechanisms are described to establish Ethernet PBB-TE point to point 70 (P2P) and point to multipoint (P2MP) connections. This document 71 supports, but does not modify, the standard IEEE data plane. 73 Table of Contents 75 1 Introduction ........................................... 4 76 1.1 Co-authors ............................................. 4 77 2 Terminology ............................................ 5 78 2.1 PBB-TE and GMPLS Terminology ........................... 5 79 3 Creation and Maintenance of PBB-TE paths using GMPLS ... 6 80 3.1 Shared Forwarding ...................................... 9 81 3.2 P2P Connections Procedures for Shared Forwarding ....... 10 82 4 Specific Procedures .................................... 11 83 4.1 P2P Ethernet LSPs ..................................... 11 84 4.1.1 P2P Path Maintenance ................................... 12 85 4.2 P2MP Ethernet-LSPs ..................................... 12 86 4.3 PBB-TE Ethernet Label .................................. 13 87 4.4 Protection Paths ....................................... 13 88 4.5 Service Instance Identification ....................... 13 89 5 Error conditions ....................................... 15 90 5.1 ESP-VID related errors ............................... 15 91 5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 16 92 5.1.2 Allocated ESP-VID range is exhausted .................. 16 93 5.2 Invalid MAC Address .................................... 16 94 6 Security Considerations ................................ 17 95 7 IANA Considerations .................................... 17 96 8 References ............................................. 18 97 8.1 Normative References ................................... 18 98 8.2 Informative References ................................. 19 99 9 Acknowledgments ........................................ 19 100 10 Author's Address ....................................... 20 102 Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 106 in this document are to be interpreted as described in [RFC2119]. 108 1. Introduction 110 The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) 111 [IEEE 802.1Qay] standard supports the establishment of explicitly 112 routed traffic engineered paths within Provider Backbone Bridged 113 (PBB) networks. PBB-TE allows disabling of: 114 - the Spanning Tree Protocol 115 - unknown destination address forwarding 116 - source address learning 117 for administratively selected VLAN Identifiers. With PBB-TE an 118 external provisioning system or control plane can be used to 119 configure static entries in the managed objects of bridges and so 120 establish traffic engineered paths in the network. 122 Generalized MPLS (GMPLS) [RFC3945] is a family of control plane 123 protocols designed to operate in connection oriented and traffic 124 engineering transport networks. GMPLS is applicable to a range of 125 network technologies including Layer 2 Switching capable networks 126 (L2SC). The purpose of this document is to specify extensions for a 127 GMPLS based control plane to manage PBB-TE explicitly routed traffic 128 engineered paths. This specification is complementary to with the 129 GMPLS Ethernet Label Switching Architecture and Framework [RFC5828] 130 document. 132 1.1. Co-authors 134 This document is the result of a large team of authors and 135 contributors. The following is a list of the co-authors: 137 Don Fedyk (Alcatel-Lucent) 138 David Allan (Ericsson) 139 Himanshu Shah (Force10 Networks) 140 Nabil Bitar (Verizon) 141 Attila Takacs (Ericsson) 142 Diego Caviglia (Ericsson) 143 Alan McGuire (BT) 144 Nurit Sprecher (Nokia Siemens Networks) 145 Lou Berger (LabN) 147 2. Terminology 149 In addition to well understood GMPLS terms, this memo uses 150 terminology from IEEE 802.1 [IEEE 802.1ah] [IEEE 802.1Qay]: 152 - BCB Backbone Core Bridge 153 - BEB Backbone Edge Bridge 154 - B-MAC Backbone MAC 155 - B-VID Backbone VLAN ID 156 - B-VLAN Backbone VLAN 157 - CBP Customer Backbone Port 158 - CCM Continuity Check Message 159 - CNP Customer Network Port 160 - C-MAC Customer MAC 161 - C-VID Customer VLAN ID 162 - C-VLAN Customer VLAN 163 - ESP Ethernet Switched Path 164 - ESP-MAC SA ESP Source MAC Address 165 - ESP-MAC DA ESP Destination MAC Address 166 - ESP-VID ESP VLAN ID 167 - Eth-LSP Ethernet Label Switched Path 168 - IB-BEB A BEB comprising of both I and B components 169 - I-SID Ethernet Service Instance Identifier 170 - TAG An Ethernet Header Field with Type and Values 171 - MAC Media Access Control 172 - PBB Provider Backbone Bridges 173 - PBB-TE Provider Backbone Bridges Traffic Engineering 174 - PIP Provider Instance Port 175 - PNP Provider Network Port 176 - PS Protection Switching 177 - P2P Point to Point 178 - P2MP Point to Multipoint 179 - SVL Shared VLAN Learning 180 - TESI Traffic Engineering Service Instance 181 - VID VLAN ID 182 - VIP Virtual Instance Port 183 - VLAN Virtual LAN 185 2.1. PBB-TE and GMPLS Terminology 187 The PBB-TE specification [IEEE 802.1Qay] defines some additional 188 terminology to clarify the PBB-TE functions. We repeat these here in 189 expanded context to translate from IEEE to GMPLS terminology. The 190 terms bridge and switch are used interchangeably in this document. 191 The signaling extensions described here apply equally well to a PBB- 192 TE capable bridge supporting GMPLS signaling or to a GMPLS capable 193 switch supporting Ethernet PBB-TE forwarding. 195 - Ethernet Switched Path (ESP): 196 A provisioned traffic engineered unidirectional connectivity path 197 between two or more Customer Backbone Ports (CBPs) which extends 198 over a Provider Backbone Bridge Network (PBBN). The path is 199 identified by the 3-tuple . An 200 ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP 201 is analogous to a (unidirectional) point-to-point or point-to- 202 multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS 203 established ESPs. 205 - Point-to-point ESP: 206 An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 207 3- tuple identifier are the individual MAC addresses of the two 208 CBPs. 210 - Point-to-multipoint ESP: 211 An ESP among one root CBP and n leaf CBPs. The ESP-DA in the 212 ESP's 3-tuple identifier is a group MAC address identifying the n 213 leaf CBPs, and the ESP-SA is the individual MAC address of the 214 root. 215 - Point-to-Point PBB-TE service instance (P2P TESI): 216 A service instance supported by two point-to-point ESPs where the 217 ESPs' endpoints have the same CBP MAC addresses. The two 218 unidirectional ESP are forming a bidirectional service. The PBB- 219 TE standard [IEEE 802.1Qay] notes the following: for reasons 220 relating to TE service monitoring diagnostics, operational 221 simplicity, etc. the IEEE PBB-TE standard assumes that the point- 222 to-point ESPs associated with a point-to-point TESI are co- 223 routed. Support for a point-to-point TE services which comprises 224 non co-routed ESPs is problematic, and is not defined in this 225 standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P 226 TE Service instance. We use the term bidirectional Ethernet-LSP 227 for GMPLS established P2P PBB-TE Service instances. 229 3. Creation and Maintenance of PBB-TE paths using GMPLS 231 IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs 232 are created bridge by bridge (or switch by switch) by simple 233 configuration of Ethernet forwarding entries. This document describes 234 the use of GMPLS as a valid control plane for the set-up, teardown, 235 protection and recovery of ESPs and TESIs and specifies the required 236 RSVP-TE extensions for the control of PBB-TE service instances. 238 PBB-TE ESP and services are always originated and terminated on IB- 239 Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B 240 components, this is illustrated in Figure 1. A B-component refers to 241 the structure and mechanisms that support the relaying of frames 242 identified by Backbone VLANs in a Provider Backbone Bridge. An I- 243 component refers to the structure and mechanisms that support the 244 relaying of frames identified by service instances (I-SIDs) in a 245 Provider Backbone Bridge. PBB and PBB-TE relay frames with added I- 246 Component TAGs in the I-Component and VLAN TAGs in the B-Component. 247 PBB and PBB-TE forward frames based on VLAN ID in the VLAN TAG (in 248 the PBB case a B-VID) until the destination MAC address is supported 249 locally by a B-Component on this bridge indicating the destination 250 has been reached. At that point, the B-VLAN tag is removed and 251 processing or forwarding on the next TAG begins (in the PBB case an 252 I-Component TAG) until the I-Component identified by the I-SID is 253 reached. At the I-component the I-Component TAG is removed and the 254 next Ethernet type identifies the TAG etc. 256 An Ethernet service supported by a PBB-TE TESI is always attached to 257 a Customer Network Port (CNP) of the I-component. A Service Instance 258 Identifier (I-SID) is assigned for the service. I-SIDs are only 259 looked at by source and destination (edge) bridges so I-SIDs are 260 transparent to path operations and MAY be signaled. The I and B 261 components have internal ports which are connected via an internal 262 LAN. These internal ports are the Provider Instance Ports (PIPs) and 263 Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside 264 the IB-BEB. ESPs are always originated and terminated on CBP ports 265 and use the MAC address of that port. The I-Component encapsulates 266 the service frames arriving from the CNP by adding an I-SID and a 267 complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The 268 B-Component adds the ESP-VID. 270 This document defines extensions to GMPLS to establish ESPs and 271 TESIs. As it can be seen from the above this requires configuration 272 of both the I and B components of the IB-BEBs connected by the ESPs. 274 In the GMPLS control plane TE Router IDs are used to identify the IB- 275 BEBs and Backbone Core Bridges (BCBs), and TE Links describe links 276 connected to PNPs and CNPs. TE Links are not associated with CBPs or 277 PIPs. 279 Note that since multiple internal CBPs may exist an IB-BEB receiving 280 a PATH message MUST be able to determine the appropriate CBP that is 281 the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD 282 advertise the CNP TE Links in the GMPLS control plane and RSVP-TE 283 signaling SHOULD use the CNP TE Links to identify the termination 284 point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one 285 of its CNPs can locally determine which CBPs have internal 286 connectivity to the I-component supporting the given CNP. In the case 287 there are more than one suitable CBPs, and no I-SID information is 288 provided in the PATH message or previously in the associated Call 289 setup, then the IB-BEB can decide freely which CBP to assign to the 290 requested connection. On the other hand, if there is information on 291 the service (I-SID) that the given ESP will support, then the IB-BEB 292 MUST first determine which PIP and CBP is configured with the I-SID 293 and MUST assign that CBP to the ESP. 295 Backbone Edge Bridge (BEB) 296 +------------------------------------------------------+ 297 | | 298 | | 299 | I-Component Relay B-Component Relay | 300 | +-----------------------+ +---------------------+ | 301 | | +---+ | | B-VID | | 302 | | |VIP| | | +---+ +---+ | | 303 | | +---+ | +---|CBP| |PNP|------ 304 | | | | | +---+ +---+ | | 305 | | +---+ +---+ | | | | | 306 ------|CNP| |PIP|----+ | | | 307 | | +---+ +---+ | | | | 308 | +-----------------------+ +---------------------+ | 309 | | 310 | PBB Edge Bridge | 311 +------------------------------------------------------+ 313 ^--------Configured--------------^ 314 ^-----------GMPLS or Configured------^ 316 Figure 1 IB-BEBs and GMPLS identifiers 318 Control TE Router ID TE Router ID 319 Plane | (TE Link) | 320 V | V 321 +----+ | +-----+ 322 Data | | | | | 323 Plane | | V label=ESP:VID/MAC DA | | 324 -----N N----------------------------N N---------- 325 | | PBB-TE | | \ Network 326 | | / | Or 327 +----+ /+-----+ Customer 328 BCB ESP:MAC IB-BEB Facing 329 Ethernet 330 Ports 332 Figure 2 Ethernet/GMPLS Addressing & Label Space 334 PBB-TE defines the tuple of as a 335 unique connection identifier in the data plane but the forwarding 336 operation only uses the ESP-MAC DA and the ESP-VID in each direction. 337 The ESP-VID typically comes from a small number of VIDs dedicated to 338 PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement 339 that ESP-VIDs for two ESPs that form a P2P TESI be the same. 341 When configuring an ESP with GMPLS, the ESP-MAC DA and ESP-VID are 342 carried in a generalized label object and are assigned hop by hop but 343 are invariant within a domain. This invariance is similar to GMPLS 344 operation in transparent optical networks. As is typical with other 345 technologies controlled by GMPLS, the data plane receiver MUST 346 accept, and usually assigns, labels from its available label pool. 347 This, together with the label invariance requirement mentioned above, 348 result in each PBB-TE Ethernet Label being a domain wide unique 349 label, with a unique ESP-VID + ESP-MAC DA, for each direction. 351 The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P 352 TESI. 354 GMPLS Upstream Label (60 bits) 355 GMPLS Downstream Label (60 bits) 356 Upstream PBB-TE ESP 3-tuple (108 bits) 357 Downstream PBB-TE ESP 3-tuple (108 bits) 359 Table 1 Labels and ESPs 361 3.1. Shared Forwarding 363 One capability of a connectionless Ethernet data plane is to reuse 364 destination forwarding entries for packets from any source within a 365 VLAN to a destination. When setting up P2P PBB-TE connections for 366 multiple sources sharing a common destination this capability MAY be 367 preserved provided certain requirements are met. We refer to this 368 capability as Shared Forwarding. Shared forwarding is invoked based 369 on policy when conditions are met. It is a local decision by label 370 allocation at each end plus the path constraints. Shared forwarding 371 has no impact on the actual paths that are setup, but it allows the 372 reduction of forwarding entries. Shared forwarding paths are 373 identical in function to independently routed paths that share a path 374 from an intersecting bridge or link except they share a single 375 forwarding entry. 377 The forwarding memory savings from shared forwarding can be quite 378 dramatic in some topologies where a high degree of meshing is 379 required however it is typically easier to achieve when the 380 connectivity is known in advance. Normally the originating GMPLS 381 switch will not have knowledge of the set of shared forwarding paths 382 rooted on the source or destination switch. 384 Use of a Path Computation Element [RFC4655] or other planning style 385 of tool with more complete knowledge of the network configuration is 386 a way to impose pre-selection of shared forwarding with multiple 387 paths using a single forwarding entry and optimizing for both 388 directions. In this scenario the originating bridge uses the 389 LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the 390 shared forwarding labels at both ends. 392 3.2. P2P Connections Procedures for Shared Forwarding 394 The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding 395 identifier or label consisting of some number of P2P connections 396 distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- MAC SA 397 tuple. This is analogous to an LDP label merge but in the shared 398 forwarding case the ESP header contains sufficient information to 399 identify the flow to which a packet belongs. Resources can continue 400 to be allocated per LSP with Shared forwarding. 402 VLAN tagged Ethernet packets include priority marking. Priority bits 403 MAY be used to indicate Class of Service (COS) and drop priority. 404 Thus, traffic from multiple COSs could be multiplexed on the same 405 Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are 406 made based on the p-bits. This means that the queue selection can be 407 done based on a per flow (i.e., Eth-LSP + priority) basis and is 408 decoupled from the actual steering of the packet at any given bridge. 410 A bridge terminating an Eth-LSP will frequently have more than one 411 suitable candidate for sharing a forwarding entry (common ESP- 412 VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how 413 this is performed but a good choice is a path that reduces the 414 requirement for new forwarding entries by reusing common existing 415 paths. 417 The concept of bandwidth management still applies equally well with 418 shared forwarding. 420 4. Specific Procedures 422 4.1. P2P Ethernet LSPs 424 Note, PBB-TE is designed to be bidirectional and symmetrically routed 425 just like Ethernet. That is, complete and proper functionality of 426 Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In 427 the following we discuss the establishment of bidirectional Eth-LSPs. 429 Note however that it is also possible to use RSVP-TE to configure 430 unidirectional ESPs, if the UPSTREAM_LABEL is not included in the 431 PATH message. To initiate a bidirectional Eth-LSP, the initiator 432 of the PATH message MUST use the procedures outlined in [RFC3473] 433 with the following specifics: 435 1) MUST set the LSP encoding type to Ethernet (2) [RFC3471]. 437 2) MUST set the LSP switching type to "802_1 PBB-TE" suggested value 438 40. 440 3) SHOULD set the GPID to Ethernet (33) [RFC3471]. 442 4) MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where 443 the 444 ESP-VID1 is administered locally for the local MAC address: MAC1 446 5) SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to 447 influence the choice of ESP-VID/ESP-MAC DA. 449 6) MAY carry an I-SID via Call / Connection ID [RFC4974]. 451 Intermediate and egress bridge processing is not modified by this 452 document, i.e., is per [RFC3473]. However, as previously stated 453 intermediate bridges supporting the 802_1 PBB-TE switching type MUST 454 NOT modify LABEL values. 456 The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL are used 457 to create a static forwarding entry in the Filtering Database of 458 bridges at each hop for the upstream direction. This behavior is 459 inferred from the switching type which is 802_1 PBB-TE. The port 460 derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1 461 included in the PBB-TE Ethernet Label constitute the static entry. 463 At the destination, an ESP-VID (ESP-VID2) is allocated for the local 464 MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL 465 object in the RESV message. As with the PATH message, intermediate 466 bridge processing is per [RFC3473], and the LABEL object MUST be 467 passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained 468 in the LABEL Object is installed in the forwarding table as a static 469 forwarding entry at each hop. This creates a bidirectional Eth-LSP as 470 the PATH and RESV messages follow the same path. 472 4.1.1. P2P Path Maintenance 474 Make before break procedures can be employed to modify the 475 characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP 476 ID in the sender template is updated as the new path is signaled. The 477 procedures (including those for shared forwarding) are identical to 478 those employed in establishing a new LSP, with the extended tunnel ID 479 in the signaling exchange ensuring that double booking of an 480 associated resource does not occur. 482 Where individual paths in a protection group are modified, signaling 483 procedures MAY be combined with Protection Switching (PS) 484 coordination to administratively force PS switching operations such 485 that modification is only ever performed on the protection path. PS 486 is a native capability of PBB-TE [IEEE 802.1Qay] that can operate 487 when two paths are set up between two common end points. 489 4.2. P2MP Ethernet-LSPs 491 PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this 492 case the PBB-TE Ethernet Label consists of a VID and a Group MAC 493 address. The procedures outlined in [RFC3473] and [RFC4875]could be 494 adapted to signal P2MP LSPs for the source (point) to destination 495 (multipoint) direction. Each one of the branches of the P2MP Eth-LSP 496 would be associated with a reverse path symmetric and congruent P2P 497 Eth-LSP. 499 Complete procedures for signaling bidirectional P2MP are out of scope 500 for this document. 502 4.3. PBB-TE Ethernet Label 504 The PBB-TE Ethernet Label is a new generalized label with the 505 following format: 507 0 1 2 3 508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | ESP MAC | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 3 PBB-TE Ethernet Label 516 This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth- 517 LSPs the fields specify a VID and a unicast MAC address, while for 518 P2MP Eth-LSPs a VID and a group MAC address is carried in the label. 519 The PBB-TE Ethernet Label is a domain wide unique label and MUST be 520 passed unchanged at each hop. This has similarity to the way in which 521 a wavelength label is handled at an intermediate bridge that cannot 522 perform wavelength conversion, and is described in [RFC3473]. 524 4.4. Protection Paths 526 When protection is used for path recovery it is required to associate 527 the working and protection paths into a protection group. This is 528 achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION 529 and PROTECTION objects. 531 4.5. Service Instance Identification 533 The I-SID is used to uniquely identify services within the network. 534 Unambiguous identification is achieved by ensuring global uniqueness 535 of the I-SIDs within the network or at least between any pair of edge 536 bridges. On IB-BEBs the Backbone Service Instance Table is used to 537 configure the mapping between I-SIDs and ESPs. This configuration can 538 be either manual or semi-automated by signaling described here. 540 RSVP-TE Signaling MAY be used to automate I-SID to ESP mapping. By 541 relying on signaling it is ensured that the same I-SID is assigned to 542 the service and mapped to the same ESP. Note, by signaling the I-SID 543 associated to the ESP one can ensure that IB-BEBs select the 544 appropriate CBP port. 546 CALL signaling [RFC4974] MAY be used to create an association between 547 the Eth-LSP endpoints prior to establishment of the LSP. The 548 CALL_ATTRIBUTES object can be used during CALL signaling as described 549 in [RFC4974] to indicate properties of the CALL. The Service ID TLV 550 defined below can be carried in the CALL_ATTRIBUTES object to 551 indicate the I-SID to ESP mapping for the Eth-LSP that will be set up 552 in association with the CALL. 554 Alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID 555 association using the Service ID TLV in the LSP_ATTRIBUTES object 556 [RFC5420] at the time of Eth-LSP signaling. Using this mechanism, it 557 is possible to create the I-SID association either when the path is 558 set up or at a later time using a PATH refresh. 560 A new Service ID TLV is defined for the CALL_ATTRIBUTES and 561 LSP_ATTRIBUTES objects. The format is depicted below. 563 0 1 2 3 564 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type (TBA) | Length (variable) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | I-SID Set 1 | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 : : : 571 : : : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | I-SID Set n | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 4 Service ID TLV 577 - Flags: are used to control properties of service configuration. 578 This document does not define flags. 580 - I-SID Set TLV(Type 1): is used to define a list or range of I- 581 SIDs. Multiple I-SID Set TLVs can be present. At least one I-SID 582 Set TLV MUST be present. In most of the cases a single I-SID Set 583 with a single I-SID value is used. The I-SID Set TLV is used to 584 define a list or range of I-SIDs. The format of the I-SID Set TLV 585 is based on the LABEL_SET Object: 587 0 1 2 3 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Action | Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Reserved | I-SID 1 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 : : : 595 : : : 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reserved | I-SID n | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 5 I-SID Set TLV 600 - Action: 8 bits 602 The following actions are defined: list (0), range (1). When a 603 range is defined, there are only two I-SIDs that follow the 604 beginning I-SID and the end of the range I-SID. When list is 605 defined, a number of I-SIDs may be defined. 606 - I-SID: 24 bits 608 The I-SID value identifies a particular backbone service 609 instance. 611 5. Error conditions 613 The following errors identify Eth-LSP specific problems. 615 In PBB-TE a set of ESP-VIDs allocated to PBB-TE must be configured. 616 Therefore it is possible in some situations that the configuration of 617 a bridge is not the same as other bridges. If the ESP-VIDs of various 618 bridges have some ESP-VIDs in common it is possible some paths may be 619 set up before encountering issues. This is a management issue since 620 all bridges should have the same ESP-VID range. Configuration should 621 be consistent. 623 5.1. ESP-VID related errors 625 The network operator administratively selects a set of VLAN 626 Identifiers that can be used to setup ESPs. Consequently, any VID 627 outside the allocated range is invalid and an error MUST be generated 628 where the mismatch is discovered. The Error indication is carried in 629 the PathErr message from any intermediate bridge that does not 630 support the signaled source VID or optionally the destination VID. 631 The Error MAY be indicated in the ResvErr if the allocation error 632 happens on the RESV message. In this case a bridge that does not 633 support the signaled destination VID MUST signal the error. 635 5.1.1. Invalid ESP-VID value in the PBB-TE Ethernet Label 637 If a bridge is not configured to use the ESP-VID value, carried in 638 the Label object, for PBB-TE ESPs, it MUST immediately generate an 639 error: Routing problem (24) / Unacceptable label value (6). Handling 640 of this error is according to [RFC3209]. 642 Note that an originating Bridge can reuse an ESP-VID with a different 643 source or destination B-MAC address. By allocating a number of B- 644 MACs and a number of ESP-VIDs a large number of PBB-TE connections 645 may be supported. 647 Note, this error may be originated by any bridge along the path. 649 5.1.2. Allocated ESP-VID range is exhausted 651 The destination bridge after receiving the PATH message has to 652 allocate a VID, which together with its MAC address will constitute 653 the PBB-TE Ethernet Label. Depending on the size of the allocated 654 VLAN range and the number of Eth-LSPs terminated on a particular 655 bridge, it is possible that the available VIDs are exhausted and 656 hence no PBB-TE Ethernet Label can be allocated. In this case the 657 destination bridge SHOULD generate a PathErr message with error code: 658 Routing problem (24) and error value: MPLS Label allocation failure 659 (9). 661 5.2. Invalid MAC Address 663 IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q] 664 that have special meaning, processing and follow specific forwarding 665 rules. These addresses cannot be used for PBB-TE ESPs. In the case 666 the PBB-TE Ethernet Label refers to such a MAC address, a bridge 667 encountering the mismatch MUST immediately generate an error: Routing 668 problem (24) / Unacceptable label value (6). Handling of this error 669 is according to [RFC3209]. 671 6. Security Considerations 673 This document does not introduces new security issues; the 674 considerations in [RFC4872] and [RFC4873] apply. 676 GMPLS controlled Ethernet PBB-TE system assumes that users and 677 devices attached to UNIs may behave maliciously, negligently, or 678 incorrectly. Intra-provider control traffic is trusted to not be 679 malicious. In general, these requirements are no different from the 680 security requirements for operating any GMPLS network. Access to the 681 trusted network will only occur through the protocols defined for the 682 UNI or NNI or through protected management interfaces. 684 When in-band GMPLS signaling is used for the control plane the 685 security of the control plane and the data plane may affect each 686 other. When out-of-band GMPLS signaling is used for the control 687 plane the data plane security is decoupled from the control plane and 688 therefore the security of the data plane has less impact on overall 689 security. 691 Where GMPLS is applied to the control of VLAN only, the commonly 692 known techniques for mitigation of Ethernet DOS attacks may be 693 required on UNI ports. PBB-TE has been designed to interwork with 694 legacy VLANs and the VLANs provide isolation from Ethernet legacy 695 control planes. 697 For a more comprehensive discussion on GMPLS security please see the 698 Security Framework for MPLS and GMPLS Networks[RFC5920]. 699 Cryptography can be used to protect against many attacks described in 700 [RFC5920]. One option for protecting "transport" Ethernet is the use 701 of 802.1AE Media Access Control Security, [MACSEC] which provides 702 encryption and authentication." 704 7. IANA Considerations 706 - Assign a new Switching Type: "802_1 PBB-TE" (suggested value 40) 707 in the GMPLS Signaling Parameters / Switching Types registry. 709 - Assign a new globally defined error value: "PBB-TE Ethernet Label 710 VID allocation failure" (suggested value: 35?) under the 711 "Routing problem" (24) error code in the RSVP Parameters / Error 712 Codes and Globally-Defined Error Value Sub-Codes registry. 714 - Assign a new type from the Attributes TLV Space in the RSVP-TE 715 Parameters registry (suggested value 2) for the Service ID TLV 716 that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type 717 = 1) [RFC5420]. 719 - Assign a new type (suggested value 2) for the Service ID TLV that 720 is carried in the CALL_ATTRIBUTES Object (class = 202, C-Type = 721 1) Registry class defined by [MLN-EXT]. 723 8. References 725 8.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label 731 Switching (GMPLS) Signaling Functional Description" IETF 732 RFC 3471, January 2003. 734 [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label 735 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 736 Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. 738 [RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label 739 Switching (GMPLS) Architecture", IETF RFC 3945, October 2004. 741 [MLN-EXT] Papadimitriou, D. et al, "Generalized Multi-Protocol 742 Label Switching (GMPLS) Protocol Extensions for Multi-Layer 743 and Multi-Region Networks (MLN/MRN)", 744 draft-ietf-ccamp-gmpls-mln-extensions, work in progress. 746 [RFC5420] Farrel, A. Ed., "Encoding of Attributes for MPLS LSP 747 Establishment Using Resource Reservation Protocol Traffic 748 Engineering (RSVP-TE), IETF RFC 5420, February 2009. 750 [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of 751 End-to-End Generalized Multi-Protocol Label Switching 752 (GMPLS)-based Recovery", RFC 4871, May 2007. 754 [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 755 2007. 757 [RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP 758 Tunnels, IETF RFC 3209, December 2001. 760 [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS) 761 RSVP-TE Signaling Extensions in Support of Calls", August 2007. 763 8.2. Informative References 765 [RFC5828] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label 766 Switching Architecture and Framework", RFC 5828, March 2010. 768 [IEEE 802.1Qay] "IEEE Standard for Local and Metropolitan Area 769 Networks - Virtual Bridged Local Area Networks 770 - Amendment : Provider Backbone Bridges Traffic Engineering 771 (2009). 773 [IEEE 802.1Q] "IEEE Standard for Local and Metropolitan Area 774 Networks - Virtual Bridged Local Area Networks", 775 IEEE Std 802.1Q-2005, May 19, 2006. 777 [IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area 778 Networks - Virtual Bridged Local Area Networks 779 - Amendment 6: Provider Backbone Bridges", (2008) 781 [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to 782 Multipoint TE LSPs", IETF RFC 4875, May 2007 784 [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) 785 Architecture", IETF RFC 4655, August 2006 787 [RFC5920] Fang, L. et.al.,"Security Framework for MPLS and GMPLS 788 Networks", RFC 5920, July 2010. 790 [MACSEC] "IEEE Standard for Local and metropolitan area networks 791 Media Access Control (MAC) Security IEEE 802.1AE-2006", 792 August 18, 2006. 794 9. Acknowledgments 796 The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen 797 Shew, Dave Martin and Sandra Ballarte for their contributions to this 798 document. The authors thank Deborah Brungard and Adrian Farrel for 799 their review and suggestions to this document. 801 10. Author's Address 803 Don Fedyk 804 Alcatel-Lucent 805 Groton, MA, 01450 806 Phone: +1-978-467-5645 807 Email: donald.fedyk@alcatel-lucent.com 809 David Allan 810 Ericsson 811 Email: david.i.allan@ericsson.com 813 Himanshu Shah 814 Force10 Networks 815 30 Nagog Park, 816 Acton, MA 01720 817 Email: hshah@force10networks.com 819 Nabil Bitar 820 Verizon, 821 40 Sylvan Rd., 822 Waltham, MA 02451 823 Email: nabil.n.bitar@verizon.com 825 Attila Takacs 826 Ericsson 827 1. Laborc u. 828 Budapest, HUNGARY 1037 829 Email: attila.takacs@ericsson.com 831 Diego Caviglia 832 Ericsson 833 Via Negrone 1/A 834 Genoa, Italy 16153 835 Email: diego.caviglia@ericsson.com 837 Alan McGuire 838 BT Group PLC 839 OP6 Polaris House, 840 Adastral Park, Martlesham Heath, 841 Ipswich, Suffolk, IP5 3RE, UK 842 Email: alan.mcguire@bt.com 843 Nurit Sprecher 844 Nokia Siemens Networks, 845 GmbH & Co. KG 846 COO RTP IE Fixed 847 3 Hanagar St. Neve Ne'eman B, 848 45241 Hod Hasharon, Israel 849 Email: nurit.sprecher@nsn.com 851 Lou Berger 852 LabN Consulting, L.L.C. 853 Phone: +1-301-468-9228 854 Email: lberger@labn.net 856 Generated on: Tue Sep 28 17:33:45 EDT 2010