CCAMP Working Group Jaihyung Cho INTERNET DRAFT ETRI Expires: May 2005 November 2004 Requirement for (G)MPLS implantation over Ethernet Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in pro- gress." 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 on February 2005. Abstract In this draft, we propose requirement to implement MPLS technology for Ethernet switched network. Ethernet has become major building block in local area network and the area of deployment is quickly expanding to core network. While there have been industry needs to overcome weakness of Ethernet, MPLS has not been considered as key technology to improve Ethernet. Currently MPLS [RFC3031] and GMPLS [GARCH] architecture do not define label-switching function on L2SC interface, i.e. over LAN media. Hence, it is necessary to discuss lightweight implementation of MPLS for Ethernet. Since there is disparity in requirements depending on hierarchy of Ethernet, it is appropriate to separate discussion in Customer Premise Network (CPN), Access Network (AN) and Core Network (CN). Some candidate methods to consider for label encoding for Ethernet are discussed. Park et al. Expires April 2005 [Page 1] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 Table of Contents: 1. Introduction................................................2 2. Candidate Methods for Label Encoding in Ethernet............3 3. Issues at Each Hierarchy of Ethernet........................4 4. Conclusion .................................................5 5. Security Considerations.....................................5 6. References..................................................5 Author's Addresses.............................................6 1. Introduction In the last several years, Ethernet has become a prevalent technology in the area of both private network and metro access network. Some network service providers now desire to push Ethernet beyond the range of MAN/WANs where long-haul technologies, such as SONET, are still dominant. The hope the network could be based entirely on Ethernet simplify network management as well as make operations more efficient and less expensive by eliminating overhead for converting between Ethernet and other technologies. However, industry experts note that Ethernet doesn't offer the scalability, reliability and quality of service that ATM and MPLS provide. There have been approaches to overcome the limitations and to extend service of Ethernet across MAN/WANs, such as [L2VPN], Provider Bridge [PBRIDGE], however, MPLS has not been considered as a scalable control mechanism for Ethernet. In current specification of MPLS architecture [RFC3031], such functionality as label switching and traffic control is only available in IP level where Ethernet service is terminated. When two MPLS nodes are connected via Ethernet switches, Ethernet nodes do not take a role in delivering labeled packets, although the actual performance bottleneck may be in Ethernet switches. GMPLS architecture [GARCH] also does not consider on L2SC interface at the moment. Given the importance of Ethernet switches in modern network, we therefore propose it is necessary to consider implementation of (G)MPLS technology for Ethernet switched network. The (G)MPLS implementation for Ethernet will be broadly characterized as employment of lightweight Internet protocol for control of Ethernet data flows. In underlying hardware layer, most data link feature and interface defined in IEEE 802.3 shall not be altered. However, intelligent signaling and routing control that understands IP protocols will be necessary in replacement to simple bridge control algorithms [STP][MSTP]. Nevertheless, this does not necessarily mean that Ethernet switches must run all essential set of MPLS protocols. Given the nature of simplicity and operational environment, much lightweight and compatible method to legacy LAN environment will be necessary. Park et al. Expires April 2005 [Page 2] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Candidate Methods for Label Encoding in Ethernet In current specification of MPLS label encoding [RFC3032], MPLS shim header does not have effect on underlying LAN media. A proprietary implementation exists that Ethernet switch decodes the shim header and forward frames according to label information [ATRICA]. While this can be a solution to employ MPLS over Ethernet, overhead to implement all processing function of label- stacks must be compared with legacy Ethernet and MPLS routers. Another option to consider is using 48bits of destination address field (and also source address field, if necessary) in Ethernet header for labels. This method was proposed in [SRINIVASAN] and [ETHREAL1] independently. S. Varadarajan demonstrated excellent capability of MAC address swapping that real-time applications receive guaranteed service without relying on priority fields [ETHREAL2][ETHREAL3]. In his method, Ethernet switches swap destination address as they forward frames. As a result, address in MAC header only has local meaning between two nodes, and real-time frames are distinguished from best-effort frames according to address block assigned for swapping operation. The method exhibits several unique characteristics. For example, it requires relatively simple modification to Ethernet hardware to support MPLS function. It also minimizes changes in user terminal in order to provide real-time service. However, Varadarajan used proprietary protocol to establish switched data path and distribute label information. His work needs further sophistication to improve inter-operability. Finally, approaches that utilize VLAN tag or stack of tags can be found in [KAWAKAMI] and [PBRIDGE]. The proposals present some potential benefit in that they make use of well-defined feature of VLAN. However, complexity and efficiency of the protocols, and merits against the method using MPLS shim header explained above must be calculate. In conclusion, there can be numerous methods for encoding label information in Ethernet. Whichever method is favored, the level of sophistication required to improve must not harm simple and economic feature of Ethernet. Park et al. Expires April 2005 [Page 3] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 3. Issues at Each Hierarchy of Ethernet The issue of (G)MPLS implementation for Ethernet can be considered separately in three different level of hierarchy; Customer Premise Network (CPN), Access Network (AN) and Core Network (CN). CPN is a local area network administered by private owner. The scale of CPN is diverse; from enterprise scale to small residential network. Deployment of Ethernet is dominant in CPN. Network congestion is hardly a problem in CPN because CPN is usually over- provisioned. However service differentiation is still necessary in order to provide secure and stable commercial service. VLAN tagging is often considered as means for flow segregation. However, commercial service providers do not trust user tagging of VLAN field because VLAN tag is easy to be modified by malicious user. Furthermore, stateless approaches that use priority field, such as DiffServe, are vulnerable to theft of service class in some environment such as University campus. A secure method to protect value-added traffic in Ethernet is necessary. MPLS provides good protection and service guarantee to customer in router network [L2VPN]. Similarly, the MAC address swapping method of [ETHREAL1] also shows several good properties to protect real- time service flows in Ethernet. However, MPLS and [ETHREAL1] both require assistance of signaling protocol and explicit path setup of which none of the kinds has been successfully deployed in local area network. There have been approaches using RSVP for proactive signaling in LAN environment [RFC2814] [RFC2815] [RFC2816] [RFC2998]. Modification of the proposals can be considered, however, the set of protocols required to support RSVP could be unacceptably heavy in some residential environment. User burden in configuring network also must be carefully examined. A simple protocol that require near-zero configuration may be necessary in CPN. In access network, deployment of Ethernet for cost-effective aggregation of subscriber lines is now a common practice in provider network. However a tradeoff to the statistical multiplexing is that access network becomes a hot spot of congestion due to high concentration of user flows. Over- provisioning in Ethernet access is meaningless because even circuit network could perform better. A method to classify flows and to provide appropriate service segregation in Ethernet level is necessary. Some QoS solutions, such as [FlOWSWITCH], require access switches or edge routers to have capability of TCP/IP header lookup in order to classify frames in application level, and dynamic setup of per- flow state for traffic policing. However, we argue that overhead for deep packet processing in access switch is unacceptably high because required role at the position is low-cost flow aggregation rather than complex packet processing. Furthermore, dynamic flow- state allocation according to TCP/IP header is also burdensome even Park et al. Expires April 2005 [Page 4] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 in edge routers because of performance and scalability concern. An explicit flow-state allocation using UNI signaling protocol may provide simple and clear solution for per-flow policing in access switch. It will also reduce burden in mid-end switches if traffic aggregates are properly marked at access switches. Hence, (G)MPLS implementation for Ethernet access switches need to seek solution for light-weight UNI signaling and forefront tagging of MPLS labels in order to facilitate efficient label switching in core network. Meanwhile in core network, it is envisaged that high-performance Ethernet switches may takeover the role of sophisticated routers in some provider network. In network where layer-2 switches constitute core, different set of requirements must be satisfied. Reliability, scalability and quality of service are the issues frequently raised. The main concept and features developed for MPLS routers can be modified and employed for Ethernet. However some simplification is necessary due to limitation in expressing divers functions using MAC header. 4. Conclusion In overall, while the solutions for (G)MPLS implementation at each hierarchy of Ethernet may independently be developed, the solutions must provide inter-operability with MPLS network. It is also noted that efficiency is usually not the prime concern than simplicity because Ethernet will lose competitiveness to routers if any added complexity overrides economic merit. 5. Security Considerations The issues are addressed in section 3 6. References [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, Jan. 2001 [GARCH] Eric Mannie, "Generalized Multi-Protocol Label Switching Architecture", IETF draft-ietf-ccamp- gmpls-architecture-07.txt, May 2003 [L2VPN] Loa Andersson, Eric C. Rosen, "L2VPN Framework", draft-ietf-l2vpn-l2-framework-03.txt, Oct. 2003 Park et al. Expires April 2005 [Page 5] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 [PBRIDGE] IEEE, "Provider Bridges", 802.1ad, work in progress [KAWAKAMI] T. Kawakami et al., "Method to Setup LSP using VLAN Tag Switching", draft-kawakami-mpls-lsp- vlan-00.txt, Feb. 2003 [STP] IEEE, "Media Access Control (MAC) Bridges",802.1D, ANSI/IEEE Standard Document, 1998 [MSTP] IEEE "Multiple Spanning Trees", 802.1s, 2002 [RFC2814] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks", RFC 2814, May 2000 [RFC2815] M. Seaman, A. Smith, E. Crawley, J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000 [RFC2816] A. Ghanwani, W. Pace, V. Srinivasan, A. Smith, M. Seaman, "A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies", RFC 2816, May 2000 [RFC2998] Y. Bernet, et. al, A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, Nov. 2000 [RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding", RFC 3032, Jan. 2001 [ATRICA] Atrica, http://www.atrica.com [SRINIVASAN] D. Bussiere, H. Esaki, A. Ghanwani, S. Matsuzawa, J.W.Pace,V.Srinivasan,"Labels for MPLS over LAN Media", draft-srinivasan-mpls-lans-label-00.txt, Aug.1997 [ETHREAL1] S. Varadarajan, T. Chiueh, "EtheReal: a host-transparent real-time Fast Ethernet switch", Sixth International Conference on Network Protocols, p12-21,1998 [ETHREAL2] S. Varadarajan, "Experiences with EtheReal: a fault-tolerant real-time Ethernet switch", ETFA 2001. 8th International Conference on Emerging Technologies and Factory Automation, Proceedings, vol.1, p183-194, 2001 [ETHREAL3] S. Varadarajan, T. Chiueh, "Automatic fault detection and recovery in real time switched Ethernet networks", IEEE INFOCOM '99, vol.1, p161-169, 1999 [FLOWSWITCH] J. W. Roberts, "Internet Traffic, QoS, and Pricing", Proceedings of the IEEE, vol.92, no. 9, p1389-1399, sep. 2004 Authors' Addresses Jaihyung Cho BcN Lab. ETRI 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Park et al. Expires April 2005 [Page 6] INTERNET-DRAFT Link Scoped IPv6 Multicast Addresses October 2004 Phone: +82 42 860 5514 Email: jspark@pec.etri.re.kr 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. 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Park et al. Expires April 2005 [Page 7]