idnits 2.17.00 (12 Aug 2021) /tmp/idnits59078/draft-fedyk-gmpls-ethernet-ivl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 710. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6055 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PWE' is mentioned on line 106, but not defined == Missing Reference: 'GMPLS-SIGNALLING' is mentioned on line 338, but not defined == Unused Reference: 'GMPLS-ARCH' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SIGNALING' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ROUTING' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'LMP' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'PATH-COMP' is defined on line 667, but no explicit reference was found in the text == Outdated reference: draft-ietf-pce-architecture has been published as RFC 4655 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Don Fedyk, David Allan 3 Document: draft-fedyk-gmpls-ethernet-ivl-00.txt Nortel 4 Category: Standards Track October 2005 6 GMPLS control of Ethernet IVL Switches 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire in April, 2006. 34 Copyright Notice Copyright (C) The Internet Society (2005). 36 Abstract 38 This memo describes how GMPLS signaling may be applied to 39 appropriately configured Ethernet Independent VLAN Learning capable 40 switches in order to configure Ethernet switched paths. 42 1. Introduction 44 Ethernet switches are growing in capability. As a consequence the 45 role of Ethernet is rapidly expanding in networks that were the 46 domain of other technologies such as SONET/SDH TDM and ATM. The 47 question of how Ethernet will evolve and what capabilities it can 48 offer in these areas is still under development. 50 GMPLS Control of Ethernet IVL Switches 52 This draft explores some unique capabilities that Ethernet has and 53 blends them with some of the values of control planes developed in 54 the IETF. 56 The techniques for repurposing Ethernet switching outlined in this 57 draft have been introduced elsewhere as a complement to 802.1ah 58 Provider Backbone Bridging under the title "Provider Backbone 59 Transport". 61 2. Terminology 63 In addition to well understood GMPLS terms, this memo uses 64 terminology from IEEE 802.1 and introduces a few new terms: 66 B-MAC Backbone MAC 67 B-VID Backbone VLAN ID 68 B-VLAN Backbone MAC 69 C-MAC Customer MAC 70 C-VID Customer VLAN ID 71 DA Destination Address 72 ESP Ethernet Switched Path 73 IVL Independent VLAN Learning 74 PBB Provider Backbone Bridge 75 PBT Provider Backbone Transport 76 SA Source Address 77 S-VID Service VLAN ID 79 3. IVL Overview and ability to configure Ethernet Switched Paths 81 Ethernet as specified today is a system. How spanning tree, data 82 plane flooding and MAC learning combine to populate forwarding 83 tables and produce resilient any-to-any behavior in a bridged 84 network is well understood. 86 What is less obvious is that the resulting behavior is purely a 87 consequence of this particular combination of functions combined 88 with what the underlying hardware can do, and that by simply 89 disabling some Ethernet functionality, it is possible to employ 90 alternative control planes and obtain different forwarding 91 behaviors. 93 GMPLS Control of Ethernet IVL Switches 95 Customer Provider Provider 96 Bridge/ Bridge Backbone 97 Bridge 99 C-MAC/C-VID------------------802.1Q ------------------C-MAC-CVID 100 S-VID-----------802.1ad------------S-VID 101 B-MAC---802.1ah---B-MAC 102 B-VID---802.1ah---B-VID 104 Figure 1 802.1 MAC/VLAN Hierarchy 106 Recent work in [PWE] and IEEE 802 are leading to a separation of 107 Ethernet functions permitting an increasing degree of carrier 108 control. So while the Ethernet service to the customer appears the 109 same, the carrier components and behaviors have become decoupled 110 from the customer presentation. 112 One example of this is the 802.1ah work in hierarchical bridging. 113 Once the carrier is in exclusive control of their Ethernet sub- 114 network and all customer specific state pushed to the edges of 115 that sub-network, the ability of the carrier to exploit latent 116 Ethernet behavior is facilitated. One key capability is to 117 overcome limitations imposed by bridging. 119 Bridging offers a simple solution for any-to-any connectivity 120 within a VLAN partition but attempting to use degenerate forms of 121 bridged connectivity for point to point services puts strain on 122 the control plane for forwarding and learning and may not offer 123 the engineerability that providers require in offering P2P 124 services. It is easier to modify Ethernet to scale engineered P2P 125 as a special case than to specify forms of any-to-any that are so 126 scalable that consumption of any-to-any transport instances for 127 point to point connectivity is inconsequential. 129 Ethernet Switches may perform Individual B-VLAN Learning (IVL) 130 based unicast forwarding on the basis of a B-VID/B-MAC tuple. This 131 means the forwarding hardware performs a full 60 bit lookup (B-VID 132 (12) + B-MAC DA (48)) only requiring uniqueness of the full 60 133 bits for forwarding to resolve correctly. 135 We can redefine the semantics of the constituent elements and get 136 complete route freedom for each 60 bit entry so long as the 137 overall requirement for global uniqueness is maintained. For 138 compatibility and flexibility reasons, it makes sense to preserve 139 the global uniqueness and semantics of MAC addresses as interface 140 names, but we can redefine the semantics associated with 141 administration and use of VLAN values. 143 We partition the B-VID space and allocate a range of B-VIDs (say 144 'n' B-VIDs) as only significant when combined with a destination 145 B-MAC address. We can then consider a B-VID in that range as an 146 individual instance identifier for one of a maximum of 'n' P2P 147 connections or MP2P multiplexed connections (subsequently termed 149 GMPLS Control of Ethernet IVL Switches 151 "shared forwarding" to distinguish from simple merges) terminating 152 at the associated destination MAC address. While a B-VID in the 153 allocated range is not unique on an Ethernet subnetwork basis, the 154 B-VID/DA tuple is, and procedures can be designed to delegate 155 administration of the allocated VID range to the node/interface 156 identified by the DA MAC. 158 This technique results in a single unique and invariant identifier 159 or label associated with the path termination and not a sequence 160 of local identifiers associated with the individual link 161 terminations. One consequence of this particular allocation is 162 there can be up to 4094 labels to any one destination MAC address, 163 a space that is consider large for P2P applications and overkill 164 when shared forwarding is leveraged. In practice, most network 165 scaling requirements may be met via delegation of only a small 166 portion of the VID space, resulting in minimal impact of the 167 number of bridging VLANs that can be supported in addition to this 168 behavior. 170 In order to use this unique 60 bit label, we then disable the 171 normal mechanisms by which Ethernet populates the forwarding table 172 for the allocated range of B-VIDs, and use a separate control or 173 management plane to populate the forwarding table. When we do that 174 for a specific label across a contiguous sequence of IVL capable 175 Ethernet switches, this will create a unidirectional connection or 176 Ethernet Switched Path (ESP). A bi-directional path is composed of 177 two unidirectional paths. The technique does not require the VID 178 to be common in both directions. Just as is the case for regular 179 Ethernet these paths are preferred to be symmetrical such that a 180 single bidirectional connection is composed of unidirectional 181 paths that have common routing in the network. 183 There are a few modifications required to standard Ethernet to 184 make this approach robust: 186 1. In Standard Ethernet, discontinuities in forwarding table 187 configuration in the path of a connection will normally result in 188 packets being flooded as "unknown". In the proposed point to point 189 case this is unnecessary and potentially catastrophic in meshed 190 topologies, therefore "unknown" flooding must be disabled for the 191 broadcast/multicast traffic. 193 2. B-MAC learning is not required for the ESP, and may interfere 194 with management/control population of the forwarding tables. For 195 this reason Provider B-MAC learning is disabled for the allocated 196 B-VID range. 198 3. Blocking must be disabled to achieve complete configured route 199 freedom. Similarly a configured path is assumed to be loop free. 200 Spanning tree is disabled for the allocated B-VID range. 202 GMPLS Control of Ethernet IVL Switches 204 4. Robustness is enhanced with the addition of data plane OAM to 205 provide both fault and performance management. How the hardware 206 performs unicast packet forwarding of known MAC addresses is 207 unmodified from how Ethernet currently works, so the OAM currently 208 defined [802.1ag, Y.17ethoam] can also be reused without 209 modification of the protocols, but with slightly altered semantics 210 (primarily w.r.t. implementation scaling variations). An 211 additional benefit of global path identifiers for dataplane 212 forwarding is the tight coupling of the 60 bit unique connection 213 ID (B-VID + B-MAC:DA) and the associated OAM packets. It is a 214 simple matter to determine lost or misdirected packet because the 215 unique connection ID cannot be altered. 217 Ethernet VLAN tags include priority tagging in the form of the 218 802.1p priority bits. When combined with configuration of the 219 paths via management or control plane, this produces the Ethernet 220 equivalent of MPLS TE E-LSPs and L-LSPs. Priority tagged Ethernet 221 PDUs self-identify the required queuing discipline independent of 222 the configured connectivity. This significantly simplifies the 223 task of signaling scalable connectivity. 225 4. Deployment Scenarios 227 This technique of GMPLS controlled Ethernet switching is 228 applicable to all deployment scenarios considered by the design 229 team [CCAMP-ETHERNET]. 231 5. Path creation and maintenance 233 One simple mode of path creation described earlier is 234 configuration. Node by node a path can be created by simple 235 configuration or by a set of commands originating from a 236 management station. 238 One improvement to node by node configuration is to look at single 239 ended provisioning and signaling. Since this is the domain of 240 CCAMP and GMPLS we will discuss the applicability of GMPLS to this 241 problem. 243 5.1.1 Using a GMPLS Control Plane for IVL 245 GMPLS has been adapted to the control of optical switches for the 246 purpose of management optical paths. GMPLS signaling is well 247 suited to setup paths with labels but it does require a minimal IP 248 control plane and IP connectivity so it is suited to certain 249 scenarios where a large number of paths or dynamic path management 250 of IVL is required. 252 In many situations for IVL the addition of a complete GMPLS 253 control plane may be overkill for the switches or the application. 254 So we well decompose the problem into Signaling, Routing, Link 255 discovery and Path management. While we discuss the options it 256 will become apparent that using all functions of GMPLS is less of 258 GMPLS Control of Ethernet IVL Switches 260 an operational overhead than any other combination. However, using 261 only some components of GMPLS can lead to more provisioned 262 parameters than a purely static system. 264 Link discovery is one of the foundations of GMPLS. It is also a 265 capability that has been specified for Ethernet in IEEE 802.1AB. 266 All link discovery is optional but the benefits of running link 267 discovery in large systems are significant. A recommendation is 268 that 802.1AB could be run with an extension to feed information 269 into an LMP based discovery. The LMP based discovery would allow 270 for a complete functional LMP for the purpose of GMPLS topology 271 discovery. LMP requires an IP control plane (as does GMPLS). 272 802.1AB does not have the ability to carry all of the LMP 273 messages. So the LMP implementation would be compatible with 274 802.1AB but add the extensions for LMP discovery. See Figure 3. 276 +---------+ +---------+ 277 | | | | 278 | LMP | ----------| LMP | 279 | +-------+ IP (opt) +-------+ | 280 | |802.1AB| ----------|802.1AB| | 281 +-+-------+ Ethernet +-------+-+ 283 Figure 3 Link Discovery Hierarchy 285 5.1.2 Control Plane Network 286 In order to have a GMPLS control plane, an IP control plane 287 consisting of and IGP with TE extension needs to be established. 288 This foundation of routing and traffic engineering parameters is 289 used to establish control channels with only minimal capability to 290 forward IP packets. 292 This IP control plane can be provided as a separate independent 293 network or integrated with the Ethernet switches. 295 If it is a separate network, it may be provided as a Layer 2 296 connected VLAN where the Ethernet switches are connection via a 297 bridged network or HUB. It may also be provided by a network that 298 provides IP connectivity where an IPVPN provides the IP 299 connectivity. 301 If it is an integrated with the switches it may be provided by a 302 bridged VLAN that uses the Data bearing channels of the network 303 for adjacent nodes. This ties the fate of IVL service and the IP 304 control plane links, but then the same Ethernet hardware is 305 already being shared. 307 5.1.3 Signaling 309 GMPLS signaling is the well suited to the set up of Ethernet 310 Switched Paths on IVL capable Ethernet switches. GMPLS signaling 311 uses link identifiers in the form of IP addresses either numbered 313 GMPLS Control of Ethernet IVL Switches 315 or unnumbered. If LMP is used the creation of these addresses can 316 be automated. If LMP is not used there is an additional 317 provisioning requirement to add GMPLS link identifiers. For large 318 implementations LMP would be beneficial. As mentioned earlier the 319 primary benefit of signaling is the control of a path from an 320 endpoint. GMPLS can be used to create bidirectional or 321 unidirectional paths, bi-directional paths being the preferred 322 mode of operation for numerous reasons (OAM consistency etc.). 324 Signaling enables the ability to dynamically establish a path and 325 to adjust the path in a coordinated fashion after the path has 326 been established. Signaling also allows multi-vendor 327 interoperability since the signaling is based on GMPLS signaling 328 protocols. This allows the network to adapt to changing conditions 329 or failures with a single mechanism. Signaling can be used in pure 330 static paths as well, but the benefit of maintaining a GMPLS 331 control plane for a pure static path application could be 332 questioned. 334 contains the B-VID/B-MAC DA tuple, which is 60 bits. On the 335 initiating and terminating nodes, a function administers the B- 336 VIDs associated with the IVL B-MAC SA and B-MAC DA respectively. 337 To initiate a bidirectional path, the initiator of the PATH 338 message uses procedures outlined in [GMPLS-SIGNALLING], it: 340 1) Sets the LSP encoding type to Ethernet. 342 2) Sets the LSP switching type to L2SC. 344 3) Sets the GPID to unknown. 346 4) Sets the UPSTREAM_LABEL to the B-VID/B-MAC SA tuple where the 347 B-VID is administered from the range reserved for IVL forwarding. 349 At intermediate nodes the UPSTREAM_LABEL object and value is 350 passed unmodified. The B-VID/B-MAC SA tuple is installed in the 351 forwarding table at each hop. 353 At the destination, a B-VID is allocated in the IVL range for the 354 B-MAC DA and the B-VID/B-MAC DA tuple is passed in the 355 GENERALIZED_LABEL in the RESV message. As with the 356 UPSTREAM_LABEL, intermediate nodes use the GENERALIZED_LABEL 357 object and pass it on unchanged, upstream. The B-VID/B-MAC DA 358 tuple is installed in the forwarding table at each hop. 360 5.1.4 IVL Label 362 The new IVL label is a new generalized label and a suggested 363 format is: 365 GMPLS Control of Ethernet IVL Switches 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |0 0 0 0| VLAN ID | MAC (highest 2 bytes) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | MAC Address | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Note that there is no syntax in signaling to force the label in 376 the UPSTREAM_LABEL and GENERALIZED_LABEL objects to be passed 377 unchanged, and so the semantics of the new label type are that the 378 wavelength label is handled at an intermediate node that cannot 379 perform wavelength conversion, and is described in [GMPLS-RSVP]. 381 5.1.5 Ethernet Service 383 Ethernet Switched Paths that are setup either by configuration or 384 signalling can be used to provide Ethernet service to customers of 385 the IVL network. The Metro Ethernet Forum has defined some 386 services in MEF.6 and MEF.11 (e.g., Ethernet Private Line), and 387 these are also aligned with ITU-T G.8011.x Recommendations. Of 388 particular interest are the bandwidth profile parameters in MEF.10 389 and whose associated bandwidth profile algorithm are based on [DS- 390 COLOR]. Consideration should be given to supporting these in any 391 signalling extensions for ESPs. This will be addressed in a future 392 version of this specification. 394 5.1.6 GMPLS Routing 396 GMPLS routing is IP routing with the TLV extensions for the 397 purpose of carrying around GMPLS TE information. The TE 398 information is populated with TE resources from LMP or from 399 configuration if LMP is not available. GMPLS Routing is an 400 optional piece but it is highly valuable in maintaining topology 401 for path management. 403 5.1.7 Path Computation 405 There has been a lot of recent activity in the area of path 406 computation. Originally MPLS path computation was performed 407 locally in a TE database on a router. While this is effective when 408 a few paths are required in a primarily connectionless 409 environment, if a large number of coordinated paths are required, 410 it is advantageous to have a more sophisticated path computation 411 engine capable of more elaborate paths. The longer lived the paths 412 and the higher bandwidth the greater the computational budget 413 required in order to get well engineered and cost effective paths. 414 This is highly dependent on topology, since in simple topologies 415 path computation is trivial. 417 GMPLS Control of Ethernet IVL Switches 419 Path computation in GMPLS generates explicit route objects (EROs) 420 that can be used directly by GMPLS signaling. 422 5.1.8 Combinations of GMPLS Features 423 can be all supported on a switch or a subset of GMPLS pieces can 424 be supported. 426 Signaling is the minimal function that might be supported on a 427 small switch. The ability to process Signaling messages with an 428 ERO may be all that is desired on an end point. 430 Routing is the next important function since it provides the 431 forwarding of signaling functions. However it is possible to 432 design switches without routing that could proxy their routing to 433 other larger switches. From the routing perspective there would be 434 little difference in the routing database but the small switches 435 would not have to perform routing operations. The information for 436 the proxied routing might be configured or it might be data filled 437 by an automated procedure. Rather than creating a new protocol it 438 is probably better to put in a full OSPF or IS-IS control plane. 440 LMP is optional as mentioned earlier. The primary benefit of LMP 441 over 802.1AB is LMP's capability for optimizing routing 442 information for the purpose of link bundling on large switches. 443 LMP has the capability to compress the information required to 444 represent a large number of parallel resources automatically. 446 Path computation is one function that is probably best done on a 447 centralized database for this application. Depending on the 448 physical topology the explicit route object (ERO) may be trivial 449 to calculate or more elaborate. Some form of path protection 450 either based on Fast Reroute techniques or local computation may 451 also be desirable for network outages but the targeted service for 452 this is long lived relatively static paths. 454 5.2 Addresses, Interfaces, and Labels 456 PBT is currently envisioned to have no explicit UNI or E-NNI which 457 simplifies the addressing of the control plane. This specification 458 uses an addressing scheme and a label space for the ingress/egress 459 connection: the hierarchical GMPLS Node Address/Port ID and the 460 Ethernet MAC/VID tuple for the delegated VID range as a label 461 space. 463 GMPLS Node Address 464 | 465 V N=named port 466 +----+ +-----+ 467 | | label=B-VLAN/B-MAC | | 468 | PB | | | 469 -----N N----------------------------N PBB N---------- 470 | | | | \ 471 | | | | Externally 472 +----+ +-----+ Facing 473 PBT Transit PBT edge Ports 474 Switch Switch 475 Figure 4 Ethernet/GMPLS Addressing & Label Space 477 Depending on how the service is defined and set up one or more of 478 these labels may be used for actual setup. It is also to be noted 479 that although it is possible for a terminating node to offer any 60 480 bit label value that can be guaranteed to be unique, the convention 481 of using MAC addresses to name specific ports is retained, an 482 Ethernet port name being common to both PBT and bridging modes of 483 operation. One implication of this is that a port index and a MAC 484 address of a port on the node may be effectively interchangeable 485 for signaling purposes, although incorrect information can result 486 in an incorrect association between a GMPLS Node Address and the 487 set of MAC named interfaces local to that node. 489 For a GMPLS based system the GMPLS Node Address/logical port is the 490 logical signaling identifier for the control plane via which 491 Ethernet layer label bindings are solicited. In order to create a 492 point to point path for IVL an association must be made between the 493 ingress and egress node. But the actual IVL label distributed via 494 signaling and instantiated in the switch forwarding tables contains 495 the egress interface name (B-MAC) of the port on the egress PBB. 496 See Figure 4. 498 GMPLS uses identifiers in the form of 32 bit number which are in 499 the IP address notation but these are not IP addresses. An IP 500 routing control plane for the propagation of TE information may be 501 supported. The provider B-MAC addresses are exchanged by the LLDP 502 and by LMP if supported. Actual label assignment is performed by 503 the signaling initiator and terminator. 505 A particular port on a Provider network node would have: 506 - A B-MAC 507 - A 32 bit IPv4 Node address r 128 bit IPv6 address plus 32 bit 508 port Identifier 509 - One (or more) Mnemonic String Identifiers 510 This multiple naming convention leaves the issue of resolving the 511 set given one of the port identifiers. On a particular node, 512 mapping is relatively straight forward. The preferred solution to 513 this is to use the GMPLS IP node address for signaling resolution. 514 In so doing, the problem of setting up a path is reduced to 515 figuring out what node supports a B-MAC address and then finding 516 the corresponding GMPLS IP node address and performing all 517 signaling and routing with respect to the GMPLS node address. 519 There are several options to achieve this: 520 - Provisioning 521 - Auto discovery protocols that carry MAC address (e.g. 802.1ab) 522 - Augmenting Routing TE with B-MAC Addresses 523 - Name Servers with identifier/address registration 524 This will be clarified in a subsequent version of this draft. 526 6. Specific Procedures 528 6.1 PT to PT connections 530 The Data Plane for IVL has three key fields. B-VID, B-MAC DA and B- 531 MAC SA. A connection instance is uniquely identified by the B-MAC 532 DA, B-VID and B-MAC SA for the purpose of the provider network 533 terminations. The B-VID and B-MAC DA tuple identifies the 534 forwarding multiplex at transit switches and a simple degenerate 535 form of the multiplex is P2P (only one SA/VID/DA connection uses 536 the VID/DA tuple). 538 This results in unique labels end to end and no merging or 539 multiplexing of tunnels. The data streams may merge but the 540 forwarding entries are unique allowing the connection to be de- 541 multiplexed downstream. 543 6.2 PT to PT connections with shared forwarding 545 The B-VID/B-MAC DA can be considered to be a shared forwarding 546 identifier for a multiplex consisting of some number of P2P 547 connections distinctly identified by the B-MAC SA/B-VID/B-MAC DA 548 tuple. 550 VLAN tagged Ethernet packets include priority marking. This means 551 that the queuing discipline applied is selectable on a per flow 552 basis and is decoupled from the actual steering of the packet at 553 any given node. As noted earlier, GMPLS signaled paths can have 554 similar properties to MPLS traffic engineered E-LSPs[MPLS-DS]. What 555 this means is that multiple Ethernet switched paths to a 556 destination may be considered functionally equivalent. This is a 557 useful property when considering setup of shared forwarding 558 Ethernet switched paths. A terminating node will frequently have 559 more than one suitable candidate path with which new path requests 560 may be multiplexed on the data plane (common VID/DA, unique SA). 562 6.3 Dynamically established P2P symmetry with shared forwarding 564 Similar to how a destination node may select a B-VID/B-MAC DA from 565 the set of existing shared forwarding multiplexes rooted at the 566 destination node, the originating node may also do so for the 567 reverse path. Once the initial ERO has been computed, the 568 originating node may select the optimal (by whatever criteria) 569 existing shared forwarding multiplex for the new destination to 570 merge with and offer its own B-VID/B-MAC DA tuple for itself as a 571 destination. This is identified via use of the UPSTREAM LABEL 572 object. 574 6.4 Planned P2P symmetry 576 Normally the originating node will not have knowledge of the set of 577 shared forwarding path rooted on the destination node. 579 Use of a Path Computation Server or other planning style of tool 580 with more complete knowledge of the network configuration may wish 581 to impose pre-selection of the a more optimal shared forwarding 582 multiplexes to use for both directions. In this scenario the 583 originating node uses the SUGGESTED LABEL and UPSTREAM LABEL 584 objects to indicate complete selection of the shared forwarding 585 multiplexes at both ends. This may also result in the establishment 586 of a new B-VID/B-MAC DA path as the SUGGESTED LABEL object may 587 legitimately refer to a path that does not yet exist. 589 7. Error conditions 591 The following errors have been identified as being unique to these 592 procedures in addition to those already defined: 594 7.1 Invalid B-VID value 596 The originator of the error is not configured to use the B-VID 597 value in conjunction with GMPLS signaling. This may be either the 598 initiating or terminating node. 600 7.2 Invalid ERO 602 The ERO offered has discontinuities with the identified VID/MAC 603 path in either the UPSTREAM LABEL or SUGGESTED LABEL objects. 605 8. Security Considerations 607 TBD. 609 9. IANA Considerations 611 TBD. 613 10.References 615 10.1 Normative References 617 [GMPLS-RSVP] Berger, L. et.al., "Generalized Multi-Protocol Label 618 Switching (GMPLS) Signaling Resource ReserVation Protocol- 619 Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, 620 January 2003 622 10.2 Informative References 624 [CCAMP-ETHERNET] Papdimitriou, D. et.al, "A Framework for 625 Generalized MPLS (GMPLS) Ethernet", internet draft, draft- 626 papadimitriou-ccamp-gmpls-ethernet-framework-00.txt , June 2005 628 [DS-COLOR] Aboul-Magd, O. et.al. "A Differentiated Service Two- 629 Rate, Three-Color Marker with Efficient Handling of in-Profile 630 Traffic", IETF RFC 4115, July 2005 632 [GMPLS-ARCH] E. Mannie, Ed., "Generalized Multi-Protocol Label 633 Switching (GMPLS) Architecture", RFC 3495. 635 [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS - 636 Signaling Functional Description", January 2003, RFC3471. 638 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in 639 Support of Generalized MPLS", work in progress. 641 [LMP] Lang. J. Editor, "Link Management Protocol (LMP)" work in 642 progress. 644 [IEEE 802.1ab] "IEEE Draft Standard for Local and Metropolitan 645 Area Networks, Station and Media Access Control Connectivity 646 Discovery" 648 [IEEE 802.1ag] "IEEE standard for Connectivity Fault Management", 649 Work in Progress, July 2005. 651 [IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", Work 652 in Progress, July 2005. 654 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services 655 Definitions - Phase I" 657 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet 658 Services Attributes Phase 1" 660 [MEF.11] The Metro Ethernet Forum MEF 11 (2004), "User Network 661 Interface (UNI) Requirements and Framework" 663 [MPLS-DS] Le Faucheur, F. et.al., "Multi-Protocol Label Switching 664 (MPLS) Support of Differentiated Services" IETF RFC 3270, May 665 2002 667 [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) 668 Architecture", Internet draft, draft-ietf-pce-architecture- 669 02.txt, September 2005 671 [Y.17ethoam] ITU-T Recommendation, "Draft Recommendation Y.17ethoam 672 - OAM Functions and Mechanisms for Ethernet based Networks " 673 work in progress, May 2005. 675 11.Author's Address 677 Don Fedyk 678 Nortel Networks 679 600 Technology Park Drive 680 Billerica, MA, 01821 681 Email: dwfedyk@nortel.com 683 David Allan 684 Nortel Networks Phone: 1-613-763-6362 685 3500 Carling Ave. Email: dallan@nortel.com 686 Ottawa, Ontario, CANADA 688 12.Intellectual Property Statement 690 The IETF takes no position regarding the validity or scope of any 691 Intellectual Property Rights or other rights that might be claimed 692 to pertain to the implementation or use of the technology described 693 in this document or the extent to which any license under such 694 rights might or might not be available; nor does it represent that 695 it has made any independent effort to identify any such rights. 696 Information on the procedures with respect to rights in RFC 697 documents can be found in BCP 78 and BCP 79. 699 Copies of IPR disclosures made to the IETF Secretariat and any 700 assurances of licenses to be made available, or the result of an 701 attempt made to obtain a general license or permission for the use 702 of such proprietary rights by implementers or users of this 703 specification can be obtained from the IETF on-line IPR repository 704 at http://www.ietf.org/ipr. 706 The IETF invites any interested party to bring to its attention any 707 copyrights, patents or patent applications, or other proprietary 708 rights that may cover technology that may be required to implement 709 this standard. Please address the information to the IETF at ietf- 710 ipr@ietf.org. 712 13.Disclaimer of Validity 714 This document and the information contained herein are provided on 715 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 716 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 717 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 718 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 719 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 720 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 721 PARTICULAR PURPOSE. 723 14.Copyright Statement 725 Copyright (C) The Internet Society (2005). This document is 726 subject to the rights, licenses and restrictions contained in BCP 727 78, and except as set forth therein, the authors retain all their 728 rights. 730 15.Acknowledgments 732 The authors would like to thank Nigel Bragg, Stephen Shew and 733 Sandra Ballarte for their extensive contributions to this document.