CCAMP Working Group Jaihyung Cho INTERNET DRAFT ETRI Expires: June 2005 January 2005 Framework for (G)MPLS implementation in Ethernet based Customer Premise Network 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 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 on June 2005. Jaihyung Cho Expires June 2005 [Page 1] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 Abstract In this draft we propose a framework for implementation of (G)MPLS technology in Ethernet based Customer Premise Network (ECPN). Major goals of this framework are improving QoS capability of Ethernet using (G)MPLS technology and facilitating secure access of commercial service, such as IP-TV or videophone, in local area network. Key solution to achieve the goal is MAC address swapping which uses 48bits of Ethernet address in MAC header as labels. Ethernet switches supporting this technique identify flows of different applications according to MAC addresses. ARP or ICMPv6 is used for terminal-to-terminal label negotiation and path establishment. Policy can be imposed in controlling user connection. Unauthorized user flows are filtered in MAC level. Compatibility with legacy Ethernet is provided best because it does not require modification in Ethernet format nor relies on VLAN tag. This architecture and technology will be aligned with architectural framework for Ethernet based Access Network and Core Network. Table of Contents: 1. Definition and Requirements for ECPN .......................2 2. Label Switched Ethernet (LSE) Technique ...................3 3. Examples of Service Scenario ..............................7 4. Conclusion ................................................11 5. Security Considerations....................................11 6. References.................................................11 Author's Addresses............................................12 1. Definition and Requirements for ECPN In the requirement draft for GMPLS implementation over Ethernet [JAIHYUNG], it was proposed to separate the solutions of GMPLS implementation for Ethernet in three level of hierarchy, Ethernet based Customer Premise Network (ECPN), Ethernet based Access Network (EAN) and Ethernet based Core Network (ECN). This document focuses on solution for ECPN. In this document, ECPN is defined as customer network of diverse capability and scale, from residential network to enterprise network. Terminal users locate in ECPN and produce various requests for network service, such as call request for high-quality videophone or channel request for HD movie. Providers must supply transmission service of satisfactory quality if the contents are charged by usage. Assuming that the provider is capable of service differentiation in certain granularity, important issues in ECPN are how to keep the original quality of traffic flow in customer network as consistent in provider network, and how to protect valuable contents from internal abuser. Reliability and security of individual communication are prime concern in network of open, Jaihyung Cho Expires June 2005 [Page 2] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 shared community, such as University campus. For example in campus network, a user may want a high-quality videophone communication using his laptop while others simply want besteffort VoIP for free. If the high-quality service is provided using a commercial service, there must be a way to secure the user flow and to provide preferential service than other flows in local network. A stateless approach such as [DiffServe] is inappropriate in this situation because it is easy to masquerade identity or manipulate service class. An explicit signaling and per-flow policy control will offer better protection and service guarantee. Other requirements as listed below must be satisfied in ECPN. - Evolutional deployment: GMPLS implementation must be operational even when the deployment is partial in a local network. Communication path of improved quality must be provided though the destination terminal is not GMPLS capable and some switches are not conforming to new implementation. - Low operational overhead: most residential users will not have professional knowledge of network. Hence the implementation must minimize manual configuration. Auto-discovery of network resources and ability for self-configuration are required. - Simple class of service: congestion is not a prime concern in ECPN because local network is usually over-provisioned. In such network, difference between multiple service classes will be negligible. Aggregation of upper layer classes into a few fundamental classes will be sufficient. - Support for coexistence of IPv4 and IPv6: the GMPLS implementation must support users of both versions. In particular, it must be able to provide data paths of satisfactory quality to IPv4 routers and IPv6 routers respectively. - Support for multicast of streaming media: Internet broadcasting of TV is already in service in some country. Streaming media will be one of dominant traffic in residential network. Reliability and quality of service are crucial factors in competing with cable TV. Fast channel zapping is an issue in IP multicasting. IGMP is too slow and vulnerable to DoS attack. Intrinsic solution for Ethernet multicast will be necessary. - Support for wireless LAN: support for mobility is one of important requirements in NGN. 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]. Jaihyung Cho Expires June 2005 [Page 3] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 2. Label Switched Ethernet (LSE) Technique In the requirements draft of [JAIHYUNG], three candidate methods for label encoding in Ethernet were discussed. The three methods have their own merits, however, MAC address swapping method as proposed in [ETHREAL1] and [SRINIVASAN], shows several good properties in providing protection and service guarantee. In this section, Label Switched Ethernet (LSE) technology that employs the idea of MAC address swapping is presented. Key improvement of LSE to the two prior works is use of ARP/ICMPv6 for lightweight LAN signaling and LSP setup. Figure 1 below describes MAC address swapping compared to typical Ethernet switching. Terminal Switch Switch Terminal [Ea]==============[S1]=================[S2]==============[Eb] b ARPreq(SA=Ea,TA=? ) ----------------> ARPreq(SA=Ea,TA=?) e ARPrsp(SA=Ea,TA=Eb) <----------------- ARPrsp(SA=Ea,TA=Eb) s t DATA(SA=Ea,DA=Eb) ----------------> DATA(SA=Ea,DA=Eb) DATA(SA=Eb,DA=Ea) <---------------- DATA(SA=Eb,DA=Ea) ............................................................ r ------- label request using ARP request or NS -----> e <------- label mapping using ARP reply or NA ------- a l DATA(SA=Ea,DA=La) -> DATA(SA=Lb,DA=Lc) -> DATA(SA=Ld,DA=Eb) DATA(SA=La,DA=Ea) <- DATA(SA=Lc,DA=Lb) <- DATA(SA=Eb,DA=Ld) Figure 1 Comparison of best-effort forwarding and real-time forwarding In the upper part of Figure 1, typical procedure for transmitting IP packet over Ethernet media is described. In the example, IP terminal Ea query Ethernet address of Eb using broadcast of ARP (Address Resolution Protocol) message. Upon receiving the broadcast message, Eb replies its MAC address in ARP reply message, as a result, terminal Ea obtains destination MAC address and transmits IP packets encapsulated in Ethernet frames. This is typical procedure for IP terminals resolving hardware address of underlying layer. Note that MAC addresses in Ethernet header are not changed when Ethernet switches forward frames. In legacy LAN, Ethernet addresses designate physical location of Ethernet device in the network. This context is slightly changed in LSE because LSE switches assign new addresses on each local link for GMPLS label when an LSP is established. Figure 2 below shows proposed format of GMPLS label Jaihyung Cho Expires June 2005 [Page 4] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 used in LSE. +------------------+--------------------+ | OUI Prefix (24) | Label (24) | +------------------+--------------------+ Figure 2: Proposed Label Format for GMPLS on LAN Media. According to MAC address format defined in ISO/IEC 8802, IEEE assigns the first 24 bits of OUI part for manufacturers. Ethernet manufacturer uses the address block of lower 24 bits to assign a global unique number on their products. In the same way, an OUI number is necessary for exclusive use of GMPLS protocol in order to avoid possible collision with physical addresses of terminals. LSE switches use the lower 24bits for labels. This ensures legacy terminals and switches coexist with new implementation. Using the labeling scheme, LSE switches allocate MAC addresses when they receive label request/mapping messages. RSVP can be used for this purpose, however, this requires RSVP implementation in all terminals and LSE switches. Furthermore, it may require pre- knowledge of routes in large-scale network in order to prevent surplus flood of RSVP messages. In LSE, ARP or Neighbor Discovery (ND) messages in ICMPv6 is used for passing information of MAC label between LSE switches. ARP has some desirable features to exploit it for GMPLS signaling. Firstly, ARP and ND are designed to carry MAC information. Using the role, it is suitable to pass MAC label information between terminals and switches. This also minimizes impact to terminals because it uses existing ARP mechanism for receiving label information. Detail of ARP procedure for LSP setup will be explained in separate draft. Secondly, the receiving party does not need to understand LSE in order to establish LSP between source and destination terminals. ARP is common protocol that any IP terminal must support. Although a destination terminal is not LSE capable, the terminal will at least respond to ARP request as with typical ARP procedure. This reaction is sufficient for LSE switches to establish LSP between two terminals. This is the strength of LSE over RFC2816 where implementation of RSVP in every terminal is pre-requisite. Thirdly, there is some correspondence between new application session and ARP action. Most network applications try to contact with unknown destination first when new session is launching. This triggers ARP transmission if subnet setting in user terminal is Jaihyung Cho Expires June 2005 [Page 5] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 proper. Hence ARP can be a sign to announce new application session in Ethernet layer. It is noted that connection-oriented feature can be brought in IP network if we utilize this property. The procedure for LSP setup and swapping of MAC address is described in the lower part of Figure 1. Detail of ARP procedure for negotiating labels is not shown in the diagram. In the ARP procedure, source terminal Ea transmits ARP to resolve Ethernet address of destination terminal Eb. LSE switches, S1 and S2, intercept this ARP request message and manipulate MAC information contained in the message. The information includes parameters necessary for establishing LSP, and it is only meaningul to LSE switches. Most terminals ignore the information. When the destination Eb responds with ARP reply, S1 and S2 allocate labels (i.e., new MAC addresses) and configure swapping entries of MAC addresses in MAC table. The label information is passed using ARP reply. In the example, S1 assigned 'La' for this flow and put this value in ARP reply message. Source terminal Ea believes that 'La' is the Ethernet address of Eb and transmits data frames using the label. When S1 receives this frame, S1 performs normal MAC table lookup using the destination address 'La' and identifies that 'La' is the label that S1 assigned for this flow and the frame requires real- time service. Note that information necessary for service classification, flow control and forwarding decision can all be obtain from simple MAC table lookup. This greatly simplifies hardware structure in implementing functions for per-flow service differentiation. Otherwise, a switch might need to check additional fields, such as VLAN tag, MPLS labels, IP header and TCP header, in order to classify type of service and application in fine grain. S1 swaps MAC addresses in the header from (DA=La, SA=Ea) to (DA=Lc, SA=Lb) when it forwards the frame. 'Lb' is the address S1 assigned on output interface and 'Lc' is the address S2 assigned on input interface for this flow. LSPs in ECPN are bi-directional that frames transmitted from S1 to S2 will have MAC addresses of (DA=Lc, SA=Lb), however in reverse direction, the addresses in the MAC header will be (DA=Lb, SA=Lc) (see Figure 1). There can be many legacy Ethernet switches locating between LSE switches or terminals, and the Ethernet switches will correctly learn the MAC addresses at both directions. Conceptually, LSE switches take the role of proxy terminals that other users listening the traffic would believe that 'Lb' is the address of Ea and 'Lc' is the address of Eb. This gives an effect of concealing actual addresses of terminals and provides some protection from malicious attack. This feature is useful in access network as well as military network where security for private Jaihyung Cho Expires June 2005 [Page 6] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 communication is important. Finally, S2 swaps MAC addresses from (DA=Lc, SA=Lb) to (DA=Eb, SA=Ld) when it forwards the frame to Eb. 'Ld' is the label that S2 assigned on output interface for this flow. Although a terminal may establish multiple LSPs, the terminal does not need to install multiple MAC addresses on interface card because LSE switch will faithfully change different labels in destination address field to actual hardware address before passing frames to final destination. The procedure for frame transmission of reverse direction is similar to above. This will not be explained in detail in this document. The LSE technique explained above is somewhat complex than typical Ethernet switching. However, added complexity is minimal because it only requires marginal increase in MAC entries and latency for header swapping. The tradeoff is improved protection and service guarantee of fine granularity comparable to MPLS routers. In essence, the swapping operation of MAC addresses has same effect as swapping of shim headers in MPLS router. However, LSE works in the context of Ethernet layer, not in IP realm. The implication is that, LSE does not require heavy protocol stacks, such as IP routing and MPLS signaling, nor heavy hardware implementation other than typical MAC table lookup, yet it brings advantage and capability of MPLS routers into Ethernet switches. LSE is new technique evolving Ethernet toward next generation. There are lots of potential areas of further sophistication. For example in backbone or access network, Ethernet switches may provide backup paths and protection service of carrier class using the technique. This will greatly enhance reliability of Ethernet switches that high-performance Ethernet switches may replace some core routers in future. It also offers versatile tool to operators that Ethernet operators may control traffic flows precisely. LSE makes Ethernet switch no longer a dumb machine but smart peer to interoperate with IP routers. 3. Examples of Service Scenario A major goal of LSE in ECPN is providing reliable platform for commercial service in private network. ARP/ICMPv6 is proposed for explicit method of accessing commercial service of provider network. Using the protocols, user applications establish lower layer connection with corresponding server or gateway, and proceed with high-level admission procedure, such as user authentication and billing, etc. Detail of service architecture and access procedure is out of scope. This section only deals with interconnection issue with provider network. While there can be many different types of access network, this document only focuses on the case that ECPN is connected via Ethernet based Access Jaihyung Cho Expires June 2005 [Page 7] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 Network (EAN). Figure 3 below shows an example that residential users request guaranteed service for commercial applications via premium service network. It is assumed that the premium service network is IPv6 and the network is dedicated for delivering value-added traffic, such as IP-TV streams or videophone flows. Server groups for user authentication, billing, application service, locate in this network. User terminals, H1~H4, are directly attached to Ethernet switch or DSLAM of LSE function, and receive most besteffort Internet service from IPv4 network. This example is selected in order to demonstrate capability for supporting both versions of IP networks. --ARP to default gateway--> /--------\ (IPv4) [H1]----| LSE |======[Default Gateway]== Besteffort Network [H2]----| based | [H3]----| DSLAM | (IPv6) [H4]----| Switch |======================Premium Service Network \--------/ | | | | | | ---NS for Premium Service--> [Auth.][Billing][Appl.] xDSL Subscribers Figure 3 A service scenario for residential users When user terminals, H1~H4, are initiated and obtain IPv4 address of default gateway, terminals issue ARP request to resolve Ethernet address of the default gateway. The LSE switch in Figure 3 assigns new MAC addresses and configures swapping entries for each besteffort flow of the terminals as the switch relays ARP messages. The LSE switch informs different MAC addresses to each terminal using ARP reply, hence establishes point-to-point LSPs for besteffort service. Access speed of Internet connection of each subscriber can be controlled according to MAC information. Ability for point-to-point service and bandwidth limiting for each subscriber are similar to PPP, however, much powerful and flexible. The besteffort LSPs will receive low priority service than LSPs established for premium service. Note that besteffort users are not aware of LSE service at all. When a user requests premium service, such as videophone communication, IPv6 application in user terminal will try to contact with corresponding application server or gateway locating in IPv6 network. This triggers transmission of Neighbor Solicitation (NS), and the LSE switch relays NS to the IPv6 network. Since ICMPv6 has rich set of optional fields, additional Jaihyung Cho Expires June 2005 [Page 8] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 information, such as authentication and encryption keys, traffic descriptors, can be piggybacked in NS. This reinforces security and reliability of LSE. When the application server admits the request, and responds with Neighbor Advertisement (NA), LSE switch assigns MAC addresses and configures swapping entries for both directions, hence establishes a bi-directional LSP for premium service. The MAC address is passed to terminal using NA. Ethernet frames that use this MAC address will receive high-priority service than other besteffort frames. Since LSE switch allocated different MAC addresses for each besteffort terminal as well as for each premium flow, service classes of the flows are identified from simple MAC table lookup. The strength of LSE over VLAN in access network is improved security and flexibility in policy control. In typical Ethernet, switches frequently broadcast frames and it can be security hazard because user data and physical addresses are exposed to other users. Malicious user may infiltrate into machines of other home user if MAC address is known. Some ISP configures port-based VLAN for each subscriber line in order to prevent user broadcast, however, this also blocks legitimate connection between users. Furthermore, this limits application of VLAN for other purpose, such as user tagging of VLAN. In contrast, LSE offers good protection because LSE switch may block broadcast of user frames and allows frame forwarding only when MAC entry is set using ARP. Physical addresses of user terminals are never exposed. It will be difficult for intruder to track down MAC address reaching a target machine if it is dynamically changed. Direct communication between users is allowed only when operator sets permission for exchanging ARP on LSE switch. Various types of policy can be imposed to control ARP negotiation between terminals. For this property, LSE provides better service and protection than legacy Ethernet in application to public network and military network. Figure 4 below shows other example of LSE application to enterprise network. In figure 4, it is assumed that a company wants to introduce integrated service of data and videophone communication using its Ethernet infrastructure. LSE switches are deployed gradually as the company upgrades old switches, 'L2' in the figure. Internet connection and data communication between users must be uninterrupted, while quality of video communication is improved as the ratio of LSE deployment is increased. The videophone can either be stand-alone type plugged in LSE switch or integrated in PC. IPv6 is assumed for videophone application, thus IPv4 and IPv6 terminals coexist in this case. Jaihyung Cho Expires June 2005 [Page 9] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 /----Enterprise Network-----\ | | | --ARP--> <--ARP | | | (IPv4) | [H1]--[L2]---\ /--[Router]==Besteffort Network | | | | | [L2]--[L2] | | | | | | [H2]--[LSE]--/ \---[LSE]====Premium Service Network | | (IPv6) | <---NS--- <-----NS----- | | \---------------------------/ Figure 4 A service scenario for enterprise network In the example above, IPv4 terminals, H1 and H2, obtain Ethernet address of gateway using ARP. When there are no LSE switches in the path of ARP negotiation, the terminal uses physical address of default gateway. However, when an LSE switch locates between a terminal and the gateway, the LSE switch intercepts ARP, allocates MAC addresses and configures swapping entries for besteffort frames. As a result, traffic flows passing LSE switches are properly managed, however the part of network that LSE is not deployed may experience unexpected traffic disturbance. Videophone applications use NS to resolve hardware address of target videophone. LSE switches establish point-to-point LSP of premium service, prior to connection procedure of application protocols. When the communicating party is an external user (public), NS must be relayed outside the enterprise network toward premium service network. The gateway of the company can be replaced to an amphibian switch that has both capability of IPv4 routing and LSE switching. However in the example, it is assumed that a dedicated LSE switch for premium service is deployed at the border of the enterprise network. NS and NA for external communication are exchanged via the border LSE switch, as a result, LSP of required resource is established. Strict policy can be imposed in the border LSE switch to prevent illegal access from public. Data frames of public network are relayed only when corresponding MAC entry exists during the application session. Contrast to typical Ethernet switch, internal data frames and physical addresses of terminals are not exposed to public because border LSE switch blocks unnecessary broadcast frames. Jaihyung Cho Expires June 2005 [Page 10] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 4. Conclusion In this draft, an LSE technique improving service and protection of Ethernet based Customer Premise Network is presented. ARP or ND is proposed for explicit signal of establishing LSP between terminals. Effectiveness of MAC address swapping in providing real-time service is proven in experimental results of S.Varadarajan [ETHREAL1] [ETHREAL2] [ETHREAL3]. Integrated service for data and real-time communication can be supported using cost-effective Ethernet hardware. ISPs are able to provide commercial services that are charged by usage per application using the architecture. Features of policy enforcement and MAC hiding improve security, and extend area of potential application to public network and military network. Similar technique and architecture will be employed in proposals for Ethernet based Access Network (EAN) and Ethernet based Core Network (ECN) in future. 5. Security Considerations The issues are addressed in section 2 6. References [JAIHYUNG] Jaihyung Cho, "Requirements for GMPLS implementation over Ethernet", draft-jaihyung-ccamp-lserequirement-00.txt, Dec. 2004. [DiffServe] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, Dec. 1998 [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 Jaihyung Cho Expires June 2005 [Page 11] INTERNET-DRAFT Framework for GMPLS implementation in ECPN January 2005 Authors' Addresses Jaihyung Cho BcN Lab. ETRI 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Phone: +82 42 860 5514 Email: jaihyung@chol.com 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. Jaihyung Cho Expires June 2005 [Page 12]