Internet Draft Don Fedyk, David Allan Document: draft-fedyk-gmpls-ethernet-ivl-00.txt Nortel Category: Standards Track October 2005 GMPLS control of Ethernet IVL Switches Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in April, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes how GMPLS signaling may be applied to appropriately configured Ethernet Independent VLAN Learning capable switches in order to configure Ethernet switched paths. 1. Introduction Ethernet switches are growing in capability. As a consequence the role of Ethernet is rapidly expanding in networks that were the domain of other technologies such as SONET/SDH TDM and ATM. The question of how Ethernet will evolve and what capabilities it can offer in these areas is still under development. Fedyk et.al Expires April 2006 Page 1 GMPLS Control of Ethernet IVL Switches This draft explores some unique capabilities that Ethernet has and blends them with some of the values of control planes developed in the IETF. The techniques for repurposing Ethernet switching outlined in this draft have been introduced elsewhere as a complement to 802.1ah Provider Backbone Bridging under the title "Provider Backbone Transport". 2. Terminology In addition to well understood GMPLS terms, this memo uses terminology from IEEE 802.1 and introduces a few new terms: B-MAC Backbone MAC B-VID Backbone VLAN ID B-VLAN Backbone MAC C-MAC Customer MAC C-VID Customer VLAN ID DA Destination Address ESP Ethernet Switched Path IVL Independent VLAN Learning PBB Provider Backbone Bridge PBT Provider Backbone Transport SA Source Address S-VID Service VLAN ID 3. IVL Overview and ability to configure Ethernet Switched Paths Ethernet as specified today is a system. How spanning tree, data plane flooding and MAC learning combine to populate forwarding tables and produce resilient any-to-any behavior in a bridged network is well understood. What is less obvious is that the resulting behavior is purely a consequence of this particular combination of functions combined with what the underlying hardware can do, and that by simply disabling some Ethernet functionality, it is possible to employ alternative control planes and obtain different forwarding behaviors. Fedyk et al. Expires April 2006 Page 2 GMPLS Control of Ethernet IVL Switches Customer Provider Provider Bridge/ Bridge Backbone Bridge C-MAC/C-VID------------------802.1Q ------------------C-MAC-CVID S-VID-----------802.1ad------------S-VID B-MAC---802.1ah---B-MAC B-VID---802.1ah---B-VID Figure 1 802.1 MAC/VLAN Hierarchy Recent work in [PWE] and IEEE 802 are leading to a separation of Ethernet functions permitting an increasing degree of carrier control. So while the Ethernet service to the customer appears the same, the carrier components and behaviors have become decoupled from the customer presentation. One example of this is the 802.1ah work in hierarchical bridging. Once the carrier is in exclusive control of their Ethernet sub- network and all customer specific state pushed to the edges of that sub-network, the ability of the carrier to exploit latent Ethernet behavior is facilitated. One key capability is to overcome limitations imposed by bridging. Bridging offers a simple solution for any-to-any connectivity within a VLAN partition but attempting to use degenerate forms of bridged connectivity for point to point services puts strain on the control plane for forwarding and learning and may not offer the engineerability that providers require in offering P2P services. It is easier to modify Ethernet to scale engineered P2P as a special case than to specify forms of any-to-any that are so scalable that consumption of any-to-any transport instances for point to point connectivity is inconsequential. Ethernet Switches may perform Individual B-VLAN Learning (IVL) based unicast forwarding on the basis of a B-VID/B-MAC tuple. This means the forwarding hardware performs a full 60 bit lookup (B-VID (12) + B-MAC DA (48)) only requiring uniqueness of the full 60 bits for forwarding to resolve correctly. We can redefine the semantics of the constituent elements and get complete route freedom for each 60 bit entry so long as the overall requirement for global uniqueness is maintained. For compatibility and flexibility reasons, it makes sense to preserve the global uniqueness and semantics of MAC addresses as interface names, but we can redefine the semantics associated with administration and use of VLAN values. We partition the B-VID space and allocate a range of B-VIDs (say 'n' B-VIDs) as only significant when combined with a destination B-MAC address. We can then consider a B-VID in that range as an individual instance identifier for one of a maximum of 'n' P2P connections or MP2P multiplexed connections (subsequently termed Fedyk et al. Expires April 2006 Page 3 GMPLS Control of Ethernet IVL Switches "shared forwarding" to distinguish from simple merges) terminating at the associated destination MAC address. While a B-VID in the allocated range is not unique on an Ethernet subnetwork basis, the B-VID/DA tuple is, and procedures can be designed to delegate administration of the allocated VID range to the node/interface identified by the DA MAC. This technique results in a single unique and invariant identifier or label associated with the path termination and not a sequence of local identifiers associated with the individual link terminations. One consequence of this particular allocation is there can be up to 4094 labels to any one destination MAC address, a space that is consider large for P2P applications and overkill when shared forwarding is leveraged. In practice, most network scaling requirements may be met via delegation of only a small portion of the VID space, resulting in minimal impact of the number of bridging VLANs that can be supported in addition to this behavior. In order to use this unique 60 bit label, we then disable the normal mechanisms by which Ethernet populates the forwarding table for the allocated range of B-VIDs, and use a separate control or management plane to populate the forwarding table. When we do that for a specific label across a contiguous sequence of IVL capable Ethernet switches, this will create a unidirectional connection or Ethernet Switched Path (ESP). A bi-directional path is composed of two unidirectional paths. The technique does not require the VID to be common in both directions. Just as is the case for regular Ethernet these paths are preferred to be symmetrical such that a single bidirectional connection is composed of unidirectional paths that have common routing in the network. There are a few modifications required to standard Ethernet to make this approach robust: 1. In Standard Ethernet, discontinuities in forwarding table configuration in the path of a connection will normally result in packets being flooded as "unknown". In the proposed point to point case this is unnecessary and potentially catastrophic in meshed topologies, therefore "unknown" flooding must be disabled for the allocated B-VID range. Flooding is similarly disabled for broadcast/multicast traffic. 2. B-MAC learning is not required for the ESP, and may interfere with management/control population of the forwarding tables. For this reason Provider B-MAC learning is disabled for the allocated B-VID range. 3. Blocking must be disabled to achieve complete configured route freedom. Similarly a configured path is assumed to be loop free. Spanning tree is disabled for the allocated B-VID range. Fedyk et al. Expires April 2006 Page 4 GMPLS Control of Ethernet IVL Switches 4. Robustness is enhanced with the addition of data plane OAM to provide both fault and performance management. How the hardware performs unicast packet forwarding of known MAC addresses is unmodified from how Ethernet currently works, so the OAM currently defined [802.1ag, Y.17ethoam] can also be reused without modification of the protocols, but with slightly altered semantics (primarily w.r.t. implementation scaling variations). An additional benefit of global path identifiers for dataplane forwarding is the tight coupling of the 60 bit unique connection ID (B-VID + B-MAC:DA) and the associated OAM packets. It is a simple matter to determine lost or misdirected packet because the unique connection ID cannot be altered. Ethernet VLAN tags include priority tagging in the form of the 802.1p priority bits. When combined with configuration of the paths via management or control plane, this produces the Ethernet equivalent of MPLS TE E-LSPs and L-LSPs. Priority tagged Ethernet PDUs self-identify the required queuing discipline independent of the configured connectivity. This significantly simplifies the task of signaling scalable connectivity. 4. Deployment Scenarios This technique of GMPLS controlled Ethernet switching is applicable to all deployment scenarios considered by the design team [CCAMP-ETHERNET]. 5. Path creation and maintenance One simple mode of path creation described earlier is configuration. Node by node a path can be created by simple configuration or by a set of commands originating from a management station. One improvement to node by node configuration is to look at single ended provisioning and signaling. Since this is the domain of CCAMP and GMPLS we will discuss the applicability of GMPLS to this problem. 5.1.1 Using a GMPLS Control Plane for IVL GMPLS has been adapted to the control of optical switches for the purpose of management optical paths. GMPLS signaling is well suited to setup paths with labels but it does require a minimal IP control plane and IP connectivity so it is suited to certain scenarios where a large number of paths or dynamic path management of IVL is required. In many situations for IVL the addition of a complete GMPLS control plane may be overkill for the switches or the application. So we well decompose the problem into Signaling, Routing, Link discovery and Path management. While we discuss the options it will become apparent that using all functions of GMPLS is less of Fedyk et al. Expires April 2006 Page 5 GMPLS Control of Ethernet IVL Switches an operational overhead than any other combination. However, using only some components of GMPLS can lead to more provisioned parameters than a purely static system. Link discovery is one of the foundations of GMPLS. It is also a capability that has been specified for Ethernet in IEEE 802.1AB. All link discovery is optional but the benefits of running link discovery in large systems are significant. A recommendation is that 802.1AB could be run with an extension to feed information into an LMP based discovery. The LMP based discovery would allow for a complete functional LMP for the purpose of GMPLS topology discovery. LMP requires an IP control plane (as does GMPLS). 802.1AB does not have the ability to carry all of the LMP messages. So the LMP implementation would be compatible with 802.1AB but add the extensions for LMP discovery. See Figure 3. +---------+ +---------+ | | | | | LMP | ----------| LMP | | +-------+ IP (opt) +-------+ | | |802.1AB| ----------|802.1AB| | +-+-------+ Ethernet +-------+-+ Figure 3 Link Discovery Hierarchy 5.1.2 Control Plane Network In order to have a GMPLS control plane, an IP control plane consisting of and IGP with TE extension needs to be established. This foundation of routing and traffic engineering parameters is used to establish control channels with only minimal capability to forward IP packets. This IP control plane can be provided as a separate independent network or integrated with the Ethernet switches. If it is a separate network, it may be provided as a Layer 2 connected VLAN where the Ethernet switches are connection via a bridged network or HUB. It may also be provided by a network that provides IP connectivity where an IPVPN provides the IP connectivity. If it is an integrated with the switches it may be provided by a bridged VLAN that uses the Data bearing channels of the network for adjacent nodes. This ties the fate of IVL service and the IP control plane links, but then the same Ethernet hardware is already being shared. 5.1.3 Signaling GMPLS signaling is the well suited to the set up of Ethernet Switched Paths on IVL capable Ethernet switches. GMPLS signaling uses link identifiers in the form of IP addresses either numbered Fedyk et al. Expires April 2006 Page 6 GMPLS Control of Ethernet IVL Switches or unnumbered. If LMP is used the creation of these addresses can be automated. If LMP is not used there is an additional provisioning requirement to add GMPLS link identifiers. For large implementations LMP would be beneficial. As mentioned earlier the primary benefit of signaling is the control of a path from an endpoint. GMPLS can be used to create bidirectional or unidirectional paths, bi-directional paths being the preferred mode of operation for numerous reasons (OAM consistency etc.). Signaling enables the ability to dynamically establish a path and to adjust the path in a coordinated fashion after the path has been established. Signaling also allows multi-vendor interoperability since the signaling is based on GMPLS signaling protocols. This allows the network to adapt to changing conditions or failures with a single mechanism. Signaling can be used in pure static paths as well, but the benefit of maintaining a GMPLS control plane for a pure static path application could be questioned. To use GMPLS RSVP-TE for signaling, a new label is defined that contains the B-VID/B-MAC DA tuple, which is 60 bits. On the initiating and terminating nodes, a function administers the B- VIDs associated with the IVL B-MAC SA and B-MAC DA respectively. To initiate a bidirectional path, the initiator of the PATH message uses procedures outlined in [GMPLS-SIGNALLING], it: 1) Sets the LSP encoding type to Ethernet. 2) Sets the LSP switching type to L2SC. 3) Sets the GPID to unknown. 4) Sets the UPSTREAM_LABEL to the B-VID/B-MAC SA tuple where the B-VID is administered from the range reserved for IVL forwarding. At intermediate nodes the UPSTREAM_LABEL object and value is passed unmodified. The B-VID/B-MAC SA tuple is installed in the forwarding table at each hop. At the destination, a B-VID is allocated in the IVL range for the B-MAC DA and the B-VID/B-MAC DA tuple is passed in the GENERALIZED_LABEL in the RESV message. As with the UPSTREAM_LABEL, intermediate nodes use the GENERALIZED_LABEL object and pass it on unchanged, upstream. The B-VID/B-MAC DA tuple is installed in the forwarding table at each hop. 5.1.4 IVL Label The new IVL label is a new generalized label and a suggested format is: Fedyk et al. Expires April 2006 Page 7 GMPLS Control of Ethernet IVL Switches 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| VLAN ID | MAC (highest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that there is no syntax in signaling to force the label in the UPSTREAM_LABEL and GENERALIZED_LABEL objects to be passed unchanged, and so the semantics of the new label type are that the label is passed unchanged. This has similarity to how a wavelength label is handled at an intermediate node that cannot perform wavelength conversion, and is described in [GMPLS-RSVP]. 5.1.5 Ethernet Service Ethernet Switched Paths that are setup either by configuration or signalling can be used to provide Ethernet service to customers of the IVL network. The Metro Ethernet Forum has defined some services in MEF.6 and MEF.11 (e.g., Ethernet Private Line), and these are also aligned with ITU-T G.8011.x Recommendations. Of particular interest are the bandwidth profile parameters in MEF.10 and whose associated bandwidth profile algorithm are based on [DS- COLOR]. Consideration should be given to supporting these in any signalling extensions for ESPs. This will be addressed in a future version of this specification. 5.1.6 GMPLS Routing GMPLS routing is IP routing with the TLV extensions for the purpose of carrying around GMPLS TE information. The TE information is populated with TE resources from LMP or from configuration if LMP is not available. GMPLS Routing is an optional piece but it is highly valuable in maintaining topology for path management. 5.1.7 Path Computation There has been a lot of recent activity in the area of path computation. Originally MPLS path computation was performed locally in a TE database on a router. While this is effective when a few paths are required in a primarily connectionless environment, if a large number of coordinated paths are required, it is advantageous to have a more sophisticated path computation engine capable of more elaborate paths. The longer lived the paths and the higher bandwidth the greater the computational budget required in order to get well engineered and cost effective paths. This is highly dependent on topology, since in simple topologies path computation is trivial. Fedyk et al. Expires April 2006 Page 8 GMPLS Control of Ethernet IVL Switches Path computation in GMPLS generates explicit route objects (EROs) that can be used directly by GMPLS signaling. 5.1.8 Combinations of GMPLS Features The combinations of LMP, Routing, Signaling and Path computation can be all supported on a switch or a subset of GMPLS pieces can be supported. Signaling is the minimal function that might be supported on a small switch. The ability to process Signaling messages with an ERO may be all that is desired on an end point. Routing is the next important function since it provides the forwarding of signaling functions. However it is possible to design switches without routing that could proxy their routing to other larger switches. From the routing perspective there would be little difference in the routing database but the small switches would not have to perform routing operations. The information for the proxied routing might be configured or it might be data filled by an automated procedure. Rather than creating a new protocol it is probably better to put in a full OSPF or IS-IS control plane. LMP is optional as mentioned earlier. The primary benefit of LMP over 802.1AB is LMP's capability for optimizing routing information for the purpose of link bundling on large switches. LMP has the capability to compress the information required to represent a large number of parallel resources automatically. Path computation is one function that is probably best done on a centralized database for this application. Depending on the physical topology the explicit route object (ERO) may be trivial to calculate or more elaborate. Some form of path protection either based on Fast Reroute techniques or local computation may also be desirable for network outages but the targeted service for this is long lived relatively static paths. 5.2 Addresses, Interfaces, and Labels PBT is currently envisioned to have no explicit UNI or E-NNI which simplifies the addressing of the control plane. This specification uses an addressing scheme and a label space for the ingress/egress connection: the hierarchical GMPLS Node Address/Port ID and the Ethernet MAC/VID tuple for the delegated VID range as a label space. Fedyk et al. Expires April 2006 Page 9 GMPLS Control of Ethernet IVL Switches GMPLS Node Address | V N=named port +----+ +-----+ <port index> | | label=B-VLAN/B-MAC | | <B-MAC> | PB | | | <string> -----N N----------------------------N PBB N---------- | | | | \ | | | | Externally +----+ +-----+ Facing PBT Transit PBT edge Ports Switch Switch Figure 4 Ethernet/GMPLS Addressing & Label Space Depending on how the service is defined and set up one or more of these labels may be used for actual setup. It is also to be noted that although it is possible for a terminating node to offer any 60 bit label value that can be guaranteed to be unique, the convention of using MAC addresses to name specific ports is retained, an Ethernet port name being common to both PBT and bridging modes of operation. One implication of this is that a port index and a MAC address of a port on the node may be effectively interchangeable for signaling purposes, although incorrect information can result in an incorrect association between a GMPLS Node Address and the set of MAC named interfaces local to that node. For a GMPLS based system the GMPLS Node Address/logical port is the logical signaling identifier for the control plane via which Ethernet layer label bindings are solicited. In order to create a point to point path for IVL an association must be made between the ingress and egress node. But the actual IVL label distributed via signaling and instantiated in the switch forwarding tables contains the egress interface name (B-MAC) of the port on the egress PBB. See Figure 4. GMPLS uses identifiers in the form of 32 bit number which are in the IP address notation but these are not IP addresses. An IP routing control plane for the propagation of TE information may be supported. The provider B-MAC addresses are exchanged by the LLDP and by LMP if supported. Actual label assignment is performed by the signaling initiator and terminator. A particular port on a Provider network node would have: - A B-MAC - A 32 bit IPv4 Node address r 128 bit IPv6 address plus 32 bit port Identifier - One (or more) Mnemonic String Identifiers Fedyk et al. Expires April 2006 Page 10 GMPLS Control of Ethernet IVL Switches This multiple naming convention leaves the issue of resolving the set given one of the port identifiers. On a particular node, mapping is relatively straight forward. The preferred solution to this is to use the GMPLS IP node address for signaling resolution. In so doing, the problem of setting up a path is reduced to figuring out what node supports a B-MAC address and then finding the corresponding GMPLS IP node address and performing all signaling and routing with respect to the GMPLS node address. There are several options to achieve this: - Provisioning - Auto discovery protocols that carry MAC address (e.g. 802.1ab) - Augmenting Routing TE with B-MAC Addresses - Name Servers with identifier/address registration This will be clarified in a subsequent version of this draft. 6. Specific Procedures 6.1 PT to PT connections The Data Plane for IVL has three key fields. B-VID, B-MAC DA and B- MAC SA. A connection instance is uniquely identified by the B-MAC DA, B-VID and B-MAC SA for the purpose of the provider network terminations. The B-VID and B-MAC DA tuple identifies the forwarding multiplex at transit switches and a simple degenerate form of the multiplex is P2P (only one SA/VID/DA connection uses the VID/DA tuple). This results in unique labels end to end and no merging or multiplexing of tunnels. The data streams may merge but the forwarding entries are unique allowing the connection to be de- multiplexed downstream. 6.2 PT to PT connections with shared forwarding The B-VID/B-MAC DA can be considered to be a shared forwarding identifier for a multiplex consisting of some number of P2P connections distinctly identified by the B-MAC SA/B-VID/B-MAC DA tuple. VLAN tagged Ethernet packets include priority marking. This means that the queuing discipline applied is selectable on a per flow basis and is decoupled from the actual steering of the packet at any given node. As noted earlier, GMPLS signaled paths can have similar properties to MPLS traffic engineered E-LSPs[MPLS-DS]. What this means is that multiple Ethernet switched paths to a destination may be considered functionally equivalent. This is a useful property when considering setup of shared forwarding Ethernet switched paths. A terminating node will frequently have more than one suitable candidate path with which new path requests may be multiplexed on the data plane (common VID/DA, unique SA). Fedyk et al. Expires April 2006 Page 11 GMPLS Control of Ethernet IVL Switches 6.3 Dynamically established P2P symmetry with shared forwarding Similar to how a destination node may select a B-VID/B-MAC DA from the set of existing shared forwarding multiplexes rooted at the destination node, the originating node may also do so for the reverse path. Once the initial ERO has been computed, the originating node may select the optimal (by whatever criteria) existing shared forwarding multiplex for the new destination to merge with and offer its own B-VID/B-MAC DA tuple for itself as a destination. This is identified via use of the UPSTREAM LABEL object. 6.4 Planned P2P symmetry Normally the originating node will not have knowledge of the set of shared forwarding path rooted on the destination node. Use of a Path Computation Server or other planning style of tool with more complete knowledge of the network configuration may wish to impose pre-selection of the a more optimal shared forwarding multiplexes to use for both directions. In this scenario the originating node uses the SUGGESTED LABEL and UPSTREAM LABEL objects to indicate complete selection of the shared forwarding multiplexes at both ends. This may also result in the establishment of a new B-VID/B-MAC DA path as the SUGGESTED LABEL object may legitimately refer to a path that does not yet exist. 7. Error conditions The following errors have been identified as being unique to these procedures in addition to those already defined: 7.1 Invalid B-VID value The originator of the error is not configured to use the B-VID value in conjunction with GMPLS signaling. This may be either the initiating or terminating node. 7.2 Invalid ERO The ERO offered has discontinuities with the identified VID/MAC path in either the UPSTREAM LABEL or SUGGESTED LABEL objects. 8. Security Considerations TBD. 9. IANA Considerations TBD. Fedyk et al. Expires April 2006 Page 12 GMPLS Control of Ethernet IVL Switches 10.References 10.1 Normative References [GMPLS-RSVP] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003 10.2 Informative References [CCAMP-ETHERNET] Papdimitriou, D. et.al, "A Framework for Generalized MPLS (GMPLS) Ethernet", internet draft, draft- papadimitriou-ccamp-gmpls-ethernet-framework-00.txt , June 2005 [DS-COLOR] Aboul-Magd, O. et.al. "A Differentiated Service Two- Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", IETF RFC 4115, July 2005 [GMPLS-ARCH] E. Mannie, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3495. [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS - Signaling Functional Description", January 2003, RFC3471. [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", work in progress. [LMP] Lang. J. Editor, "Link Management Protocol (LMP)" work in progress. [IEEE 802.1ab] "IEEE Draft Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery" [IEEE 802.1ag] "IEEE standard for Connectivity Fault Management", Work in Progress, July 2005. [IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", Work in Progress, July 2005. [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services Definitions - Phase I" [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services Attributes Phase 1" [MEF.11] The Metro Ethernet Forum MEF 11 (2004), "User Network Interface (UNI) Requirements and Framework" [MPLS-DS] Le Faucheur, F. et.al., "Multi-Protocol Label Switching Fedyk et al. Expires April 2006 Page 13 GMPLS Control of Ethernet IVL Switches (MPLS) Support of Differentiated Services" IETF RFC 3270, May 2002 [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) Architecture", Internet draft, draft-ietf-pce-architecture- 02.txt, September 2005 [Y.17ethoam] ITU-T Recommendation, "Draft Recommendation Y.17ethoam - OAM Functions and Mechanisms for Ethernet based Networks " work in progress, May 2005. 11.Author's Address Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, 01821 Email: dwfedyk@nortel.com David Allan Nortel Networks Phone: 1-613-763-6362 3500 Carling Ave. Email: dallan@nortel.com Ottawa, Ontario, CANADA 12.Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 13.Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND Fedyk et al. Expires April 2006 Page 14 GMPLS Control of Ethernet IVL Switches THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14.Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 15.Acknowledgments The authors would like to thank Nigel Bragg, Stephen Shew and Sandra Ballarte for their extensive contributions to this document. Fedyk et al. Expires April 2006 Page 15