rtgwg Mohammad A Yousuf Internet Draft Matthew R Thomas Intended status: Internet Draft June 16, 2008 David K Hunter Expires: December 2008 Martin J Reed University of Essex Chrysolite - a backbone bridging solution draft-yousuf-thomas-hunter-rtgwg-bb-02.txt 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. This document may not be modified, and derivative works of it may not be created. 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 on Nov 16, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 1] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 Chrysolite is a combination of differing technologies to create a wide area switched Ethernet solution. Each Chrysolite switch has a unique MAC address (N-MAC). A link state protocol provides pairwise shortest paths between the N-MACs (one N-MAC per switch). Customers connect to the Chrysolite cloud using Ethernet connections. By setting the locally administered bit in the Ethernet address used to connect to the Chrysolite cloud, customers can directly encapsulate traffic into assigned source and destination C-MAC (MAC) addresses. Each of these C-MAC addresses specifies a unique customer 'VLAN circuit'. This proves end to end paths across the Chrysolite cloud without requiring any special headers, MAC in MAC or Q-in-Q encapsulation. Conventions used in this document 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 0. Table of Contents 1. Changes since last version...................................3 1.1. N-MAC and C-MAC have changed meaning....................3 1.2. Removal of the UNI......................................3 2. Introduction................................................3 3. Address capacity............................................4 4. Are the N-MACs in a Hierarchy?...............................5 5. Developing a UNI............................................5 6. Customer configuration.......................................5 7. Without Customer configuration...............................5 8. MAT Mechanism for customer avoiding manual configuration......5 9. Unusual multicast (layer 2) packets..........................6 10. Example Chrysolite addressing...............................6 10.1. Structure of the MAC addresses:........................6 11. Packet types...............................................7 11.1. Unknown Packets........................................7 11.2. Broadcast packets over Chrysolite......................7 11.2.1. Reverse Path forwarding...........................8 11.3. Native MAC Multicast ingress Packets...................8 Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 2] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 11.3.1. 'Reserved' multicast N and C components...........8 12. Routing Considerations......................................8 12.1. Non multi-instance operation...........................8 12.2. MAC addresses for multi-instance operation.............8 13. Why are there only 2 C-MACs per VLAN circuit?...............9 14. Mapping differing classes of service to VLAN circuits.......11 15. Security Considerations....................................11 16. IANA Considerations........................................11 17. Conclusions...............................................12 18. References................................................12 18.1. Normative References..................................12 18.2. Informative References................................12 19. Author's Addresses........................................13 Intellectual Property Statement................................13 Disclaimer of Validity........................................14 1. Changes since last version 1.1. N-MAC and C-MAC have changed meaning. C-MAC (previously represented 'Chrysolite-MAC') but now represents the Customer-MAC as expected. N-MAC now refers to the Network-MAC, and is the Component of the MAC address assigned to each Chrysolite switch. 1.2. Removal of the UNI. On review it was clear that the functions of the UNI could be avoided by a manual configuration of the C-MACs onto the respective Ethernet interfaces. 2. Introduction The Chrysolite network is a network of Ethernet switches implemented over the WAN. Each switch is given a unique MAC address called a N- MAC. These N-MACs can be located at random in the non-hierarchical flat network. Because customers are attached to a Chrysolite switch at the edge, the identity of the physical remote and local switches are decided according to the circuit that the customer requires; i.e. if a customer wants a connection from London to Manchester, then the Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 3] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 geographically closest switches they would like to connect between are decided upon. A unique VLAN circuit number for the customer's path is assigned sequentially from the 2^24-bit range and dedicated to this path. This VLAN circuit number actually builds the endpoint destination C- MAC addresses that the customers will use to communicate. The 3-octet VLAN circuit number is added to the switch's unique first three octets of N-MAC, to build the full 6-octet C-MAC as discussed. ALL Packets entering the Chrysolite cloud are sent from the source C- MAC (built as a combination of the switch's unique 3-octets of N-MAC and the unique 3 octets of circuit C-MAC), across the cloud to the destination C-MAC (which is also built with the destination N-MAC as the first three octets and the same 3 octet circuit number). 3. Address capacity There are 2^20 possible N-MACs. The N-MACs summarize each of the 2^24 C-MACs. Each of the C-MACs can be considered as a unique endpoint to VLAN circuit. See addressing structure below. All broadcast and unknown packets common to traditional bridged networks are therefore removed, because the locally administered (/translated) C-MACs are easily identified as relating to their respective N-MACs and are routed towards their relevant Chrysolite switches using the pair-wise shortest paths. The number of pair-wise shortest paths and the size of the routing table cannot exceed the number of N-MACs (switches) in the network. The FIB table is restricted therefore to the number of Chrysolite switches in the network, whilst routing 16 million individual VLAN circuits. A MAC level link state routing protocol is used to calculate pair-wise shortest paths. Max routing table size = number of deployed Chrysolite switches Pair wise shortest paths = number of deployed Chrysolite switches SPF Heap size = number of deployed Chrysolite switches Number of unique VLAN circuits (paths) = 16 million Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 4] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 4. Are the N-MACs in a Hierarchy? It would be a mistake to think of the N-MACs as being located in a hierarchy. They can be located anywhere in the cloud and moved at any time. However each N-MAC is an aggregate of many C-MACs (VLAN circuit endpoints). 5. Developing a UNI This requirement is removed in this version as manual configuration is recommended. 6. Customer configuration The easiest way to connect to a Chrysolite cloud is by using limited manual configuration. (ref diagram 2). The C-MAC end points of customer circuits are configured on Ethernet sub-interfaces. With this configuration employed MAT is not used and the attached routers build the Ethernet packets with the endpoint C-MACs directly. Customers are required to connect to the Chrysolite cloud via Ethernet interfaces. 7. Without Customer configuration If a customer is unable to configure C-MACs onto attached Ethernet interfaces then the Chrysolite switch can MAT translate the packets received from the customer into the correct source and destination C- MACs Without configuration, the customer is limited to a single VLAN Circuit per physical Ethernet connection. 8. MAT Mechanism for customer avoiding manual configuration A standard Ethernet frame arrives at the first Chrysolite switch. From the ingress port. The packet undergoes MAT (MAC Address Translation). This is instead of traditional encapsulation. There is MAT running at both ends of the Chrysolite cloud so translation of the SA MAC address occurs on entry to the cloud. See figure 3 for an example IP ARP packet. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 5] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 9. Unusual multicast (layer 2) packets All traffic destined for the remote customer C-MACs must be correctly constructed with remote C-MAC destination addresses. If packets do not have the correct destination C-MAC, they MUST be either MAT translated or discarded and not propagated further. Normal bridge control frames destined for the Chrysolite switch itself from the router / end host are processed as normal but MUST NOT be propagated over the network. 10. Example Chrysolite addressing If the host is on VLAN circuit numbered 00-00-01 then the C-MAC component is: 00-00-01. If the ingress switch is numbered 02-00-08 (unique N-MAC component), then the switch would have a N-MAC of 02- 00-08-00-00-00, and the customer equipment would have a source C-MAC of 02-00-08-00-00-01; Note: the 0x02 is derived from having the Local bit set. The cloud MUST be made of contiguous switches that understand the Global/Local bit in the Ethernet header. 10.1. Structure of the MAC addresses: 1. Most significant 4 bits (1-4) of first Byte (on the wire) of MAC: Part of unique N-MAC 2. Least significant 4 bits (5-8) of first Byte (on the wire) of MAC: o Bit 5 = '*'reserved o Bit 6 = 'R' Routing bit o Bit 7 = Global/Local bit (set) o Bit 8 = Group bit. 3. Next two bytes of MAC: The rest of the unique N-MAC component. 4. The last 24 bits in the address represent the C-MAC component (VLAN circuit component). These represents 2^24 unique paths across the Chrysolite cloud. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 6] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 Fig. 1 Chrysolite MAC address formation. +-----------------------------------------------------------+ |msb lsb *=Reserved, R=Routing G/L=Local G=Group | |+-+-+-+-+-+-+-+-+ | |<---C--->* R G/L G Byte 1 (4 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | |<------C--------> Byte 2 (8 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | |<------C--------> Byte 3 (8 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 4 (8 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 5 (8 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 6 (8 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | | | +-----------------------------------------------------------+ 11. Packet types 11.1. Unknown Packets This architecture does not have unknown packets. All MAC addresses are known in the cloud, and are found via the 'N' portion (N-MAC)of the C-MAC addresses in much the same way that an IP packet's destination can be located within a cloud. 11.2. Broadcast packets over Chrysolite Although broadcast packets are not required for the functioning of Chrysolite, they are available. A broadcast packet would go to each of the N-MACs using the address FX-FF-FF-FF-FF-FF, where X;(0x3) represents the 4 least significant bits of the first byte on wire. The group bit is set and the local bit is always set for a broadcast packet within a Chrysolite network: o Bit 5 = '*'reserved o Bit 6 = 'R' Routing bit NOT set for a broadcast packet o Bit 7 = Global/Local bit MUST be set for all packets o Bit 8 = Group bit. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 7] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 11.2.1. Reverse Path forwarding RPF checking is done on any broadcast packets. Packets failing this check are discarded. 11.3. Native MAC Multicast ingress Packets 11.3.1. 'Reserved' multicast N and C components Special Ethernet and multicast packets with the first three octets = 01-80-C2, 01-00-5E, 00-00-5E, and 33-33-FF MUST be either MAT translated or discarded. 12. Routing Considerations A MAC level link state protocol will be used to create pair-wise shortest paths between the N-MACs of the Chrysolite switches. The following paragraphs are recommendations to employing a link state protocol with Chrysolite: 12.1. Non multi-instance operation For normal (non multi-instance operation) we recommend the protocol use the highest C-MAC address of the 'broadcast' N-MAC; FX-FF-FF with the group bit, local bit, and routing bit set. i.e. FX-FF-FF-FF-FF- FF. Where X is set to 0x7 (Routing bit set, Group bit set, and Local bit set.) 12.2. MAC addresses for multi-instance operation We recommend 8 reserved multicast addresses for implementation of a multi-instance link state routing protocol. These could range from FX-FF-FF-FF-FF-F8 through to FX-FF-FF-FF-FF-FF, where the default operation is the use of FX-FF-FF-FF-FF-FF. For multi-instance link state operation, the Chrysolite switch forming the LSA will use its N-MACs as the router ID. The routing bit is shown in Fig. 1. This informs the Chrysolite switch that the packet is a link state routing packet. The source address SHOULD be the N-MAC of the Chrysolite switch sending the link state packet. Link state routing protocol packets MUST only transition one switch hop. Note: VLAN circuit information about each Chrysolite switch is not required to be attached to the router LSA. Router LSAs SHOULD only detail directly attached neighbor's N-MACs. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 8] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 13. Why are there only 2 C-MACs per VLAN circuit? Although backbone bridging technologies regularly refer to 'customer VLANs', it is unlikely that a customer would fully bridge their real VLAN circuit wide area. A modern LAN would require a high wide area bandwidth of a similar order of magnitude if fully bridged. ARP packets and broadcasts and ALL unknowns would cross the Wide Area. Having the ARP from two local PCs cross Wide Area is not the meaning of customer VLANs. As such when we refer to customer VLANs we are assuming that a router device has terminated the real customer VLAN circuits with the associated ARPs and is actually using specific VLAN circuits for routing the relevant traffic over the WAN. With this understanding Chrysolite allows a single C-MAC address at each end of the path. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 9] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 Fig. 2 Customer configuration +-----------------------------------------------------------| | | | Ethernet 0.1 description circuit to R2 | | source mac-address | | dest mac-address | | IP address ABC | | | | Ethernet 0.2 | | source mac-address | | dest mac-address | | IP address XYZ | | | | | | | | +-+-+ +-+-+ +-+-+ +-+-+ | | | R1|--------|C1 |--Chrysolite-----|C2 |------| R2| | | +-+-+ +-+-+ switches +-+-+ +-+-+ | | H2 H2 H2 | | | | | | All packets from R1>R2 (including ARPs) | | --------------------------------------- | | Header 2 (H2) SA=R1 , DA=R2 | | | | All packets from R2>R1 (including ARPs) | | --------------------------------------- | | Header 2 (H2) SA=R2 , DA=R1 | | | +-----------------------------------------------------------+ Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 10] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 Fig. 3 Without customer configuration (Using MAT) +-----------------------------------------------------------+ | Without customer configuration | | +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+ +-+-+ +-+-+ +-+-+ | | | R1|--------|C1 |--Chrysolite-----|C2 |------| R2| | | +-+-+ +-+-+ switches +-+-+ +-+-+ | | H1 H2 H3 | | | | IP ARP request over Chrysolite VLAN circuit | | ---------------------------------- | | Header 1 (H1) SA=R1, DA=ARP | | Header 2 (H2) SA=R1-C-MAC, DA=R2-C-MAC source + dest MAT | | Header 3 (H3) SA=R1-C-MAC, DA=ARP dest MAT | | | | ARP reply | | --------- | | Header 3 (H3) SA=R2, DA=R1-C-MAC (taken from ARP request)| | Header 2 (H2) SA=R2-C-MAC, DA=R1-C-MAC source MAT | | Header 1 (H1) SA=R2-C-MAC, DA=R1 dest MAT | +-----------------------------------------------------------+ 14. Mapping differing classes of service to VLAN circuits 1. Class of service (or other required quality), can be mapped into Chysolite VLAN circuits. The differing services can be implemented in Chrysolite by using multiple parallel link state instances. Multiple N-MACs are configured per unique Chrysolite switch and multiple instances of the link state protocol are also configured. It is the selection of one of the globally unique link state MAC addresses (for multi-instance link state routing) that enables the different SPF trees to be built. 15. Security Considerations Access control lists are required on the edge Chrysolite switches to prevent malicious injection of packets to destination C-MACs not owned by the customer. Other security issues are consistent with backbone Ethernet solutions. 16. IANA Considerations None at present. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 11] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 17. Conclusions This architecture provides pair-wise shortest paths to backbone bridges. 18. References 18.1. Normative References [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MAT] Wang, P,. Cahn, C., Lin, P., "MAC Address Translation for Enabling Scalable Virtual Private LAN Services" Advanced Information Networking and Applications Workshops, Volume 1, 21-23 May 2007 Page(s):870 - 875. 18.2. Informative References [FINN] Finn, N., Provider Bridge Layer Two Protocols", IEEE 802.1 work in progress, March 2003. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 12] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 19. Author's Addresses Mohammad A. Yousuf CES Department University of Essex Colchester CO4 3SQ UK Email: mayous@essex.ac.uk Matthew R. Thomas CES Department University of Essex Colchester CO4 3SQ UK Tel:44-7940 585456 Email: mrthom@essex.ac.uk David K. Hunter CES Department University of Essex Colchester CO4 3SQ Email: dkhunter@essex.ac.uk 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. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 13] Internet-Draft Chrysolite - a backbone bridging solution Dec 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yousuf Thomas Hunter Expires Dec 16, 2008 [Page 14]