rtgwg Mohammad A. Yousuf Internet Draft Matthew R. Thomas Intended status: Internet Draft March 21, 2008 David K. Hunter Expires: September 2008 University of Essex Chrysolite - a backbone bridging solution draft-yousuf-thomas-hunter-rtgwg-bb-00.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. This document may only be posted in an Internet-Draft. 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 Sept 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 1] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 Abstract Chrysolite is a combination of differing technologies to create a wide area BB (Backbone Bridging) architecture. Each Chrysolite switch has a unique MAC address (C-MAC). A link state protocol provides pairwise shortest paths between the C-MACs (one C-MAC per switch). Each switch's C-MAC symbolically represents 2^24 Network N-MACs (with each N-MAC representing one of the endpoints of a P2P VLAN. Using MAT (MAC Address Translation) and setting the locally administered bit in the Ethernet address, Router MAC addresses attached to an edge Chrysolite switch are translated into the end-to-end N-MAC addresses of the P2P circuit that they are attached to. MAT can also be completely avoided by use of a single packet UNI explained below. ALL of the P2P location information for a packet is located in a SINGLE N-MAC address assigned to each end of the P2P VLAN 'circuits'. Using this UNI or MAT backup means that no encapsulation or special headers are required to provide pair-wise shortest paths between the Chrysolite switches. Configuration is restricted to the single unique C-MAC required per Chrysolite switch, and the recording of unique customer VLANs as they are required. 1. Introduction This draft uses MAC Address Translation MAT to provide VLAN functionality natively to BB. Pair wise shortest paths are calculated for each of the unique C-MACs (one per Chrysolite switch). There are 2^20 possible C-MACs. The C-MACs summarize each of the 2^24 N-MACs. The N-MACs can be thought of as 'network MACs' rather like an IP subnet. Each of the N-MACs can be considered as a unique endpoint to a P2P VLAN. See addressing structure below. All 'unknown packets' common to traditional bridged networks are therefore removed, because the locally administered (/translated) N- MACs are easily identified as relating to their respective C-MACs and are routed towards their relevant Chrysolite switches using the pair- wise shortest paths. As with standard switches the Chrysolite switches do not have MAC addresses on each port. The number of pair- wise shortest paths and the size of the routing table cannot exceed the number of C-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 P2P VLAN circuits. Ospf-lite [LITE] will be used as the link state routing protocol to calculate the pair-wise shortest paths. Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 2] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 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 P2P VLANs = 16 million 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. Introduction...................................................2 2. Are the C-MACs in a Heirarchy?.................................4 3. Will I be using MAT all the time?..............................4 4. Chrysolite UNI.................................................4 5. MAT Mechanism..................................................5 6. Unusual multicast (layer 2) packets............................5 7. Example Chrysolite addressing..................................5 7.1. Structure of the MAC addresses:...........................5 8. Packet types...................................................7 8.1. 'Unknown' Packets.........................................7 8.2. Native MAC Multicast ingress Packets......................7 8.2.1. 'Reserved' multicast C and N components..............7 9. Broadcast over Chrysolite......................................7 9.1.1. Reverse Path forwarding..............................7 10. Routing Considerations........................................7 10.1. MAC address for MAC level ospf-lite......................7 11. How to build a Chrysolite network.............................8 12. Why are there only 2 N-MACs per VLAN?.........................9 13. OAM...........................................................9 14. An example operation (How the MAT 'backup' works and why).....9 15. Security Considerations......................................12 16. IANA Considerations..........................................12 17. Conclusions..................................................12 18. References...................................................12 18.1. Normative References....................................12 18.2. Informative References..................................12 Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 3] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 Author's Addresses...............................................13 Intellectual Property Statement..................................13 Disclaimer of Validity...........................................14 2. Are the C-MACs in a Heirarchy? It would be a mistake to think of the C-MACs as being located in a hierarchy. They can be located anywhere in the cloud and moved at any time. They are not fixed in any way. However each C-MAC is an aggregate of many N-MACs. (P2P VLANs). 3. Will I be using MAT all the time? (Note: If the UNI is used - i.e. the router forms the MAC addresses with the N-MACs directly - then there is no MAT occurring either in the Chrysolite switch or in the attached router.) Without the UNI in operation then the following applies: for each N- MAC (VLAN) on a Chrysolite switch there is only one 'tunnel end point' N-MAC that it sends packets to and there is only one source N- MAC allowed to transmit (tunnel source). So every packet needs to have the MAC addresses swapped. The destination MAC address should normally be correct (ie will not need swapping) due to normal routing operations, but the source will need swapping. However, these 'tunnels' require connection to routers via Ethernet interfaces or 802.1Q trunks. As such the attached router can use the correct addresses if informed by the Chrysolite switch via the simple UNI. When using the single packet UNI, there is no MAT translation either on the router or on the Chrysolite switch. 4. Chrysolite UNI The Chrysolite switch will send a packet to the attached router detailing the following: o The VLAN in use, and the source and destination N-MAC addresses that should be used when encapsulating these packets. o Sequence number of information packet. The destination MAC address of the Chrysolite UNI is [TBD]. The protocol number of the packets is [TBD] Ref IANA. Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 4] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 ALL packets including broadcast or multicast that the router decides to send over the P2P 'tunnel' MUST have their destination N-MAC set to the end of the 'tunnel', and their 'source' N-MAC set to the N-MAC assigned by the Chrysolite switch. 5. MAT Mechanism A standard Ethernet frame arrives at the first Chrysolite switch. From the ingress port (or from the 802.Q header running on a trunk), the VLAN of the packet source is identified. Once the VLAN is identified, the packet undergoes MAT (MAC Address Translation). This is instead of 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 section 13 and figure 2 for a full example IP packet. 6. Unusual multicast (layer 2) packets Without the use of the UNI, the Chrysolite switch will have to MAT the DA of all unusual incoming packets to the 'tunnel' end point N- MAC. If packets do not have the correct destination N-MAC, they MUST be either MAT translated or discarded and not propagated further. This applied to all MAC addresses, including packets in the following OUI or first 3 octet ranges; 01-80-C2, 01-00-5E, 00-005E, and 33-33- FF. Normal bridge control frames destined for the Chrysolite switch itself from the router / end host are processed as normal but not propagated over the network. 7. Example Chrysolite addressing If the host is on VLAN-1 with an N-component of 00-00-01, and the ingress Chrysolite switch is numbered 03-00-08 (unique C component), then the Chrysolite switch would have a C-MAC of 03-00-08-00-00-00, and the router would have a source N-MAC of 03-00-08-00-00-01, where 03-00-08 is the C-MAC component, 00-00-01 is the P2P VLAN component (The 0x03 is derived from having both the Group and Local bits set.) 7.1. Structure of the MAC addresses: 1. most significant 4 bits of MSByte of MAC: Part of unique C-MAC Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 5] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 2. Least significant 1-4 bits of MSByte of MAC: o Bit 4 = '*'reserved o Bit 3 = 'R' Routing bit o Bit 2 = Global/Local bit (set) o Bit 1 = Group bit. 3. Next two bytes of MAC: The rest of the unique C-MAC component. 4. The last 24 bits in the address represent the N-MAC component (P2P VLAN). These represent 2^24 unique 'tunnels' across the Chrysolite cloud. MAC ADDRESSING +-----------------------------------------------------------+ |msb lsb *=Reserved, R=Routing G=Group G/L=Local | |+-+-+-+-+-+-+-+-+ | |<---C--->* R G G/L Byte 1 (4 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | |<------C--------> Byte 2 (8 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | |<------C--------> Byte 3 (8 bits of C-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 4 (8 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 5 (8 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | |<------N--------> Byte 6 (8 bits of N-MAC) | |+-+-+-+-+-+-+-+-+ | | | +-----------------------------------------------------------+ Chrysolite MAC address formation during MAT. The location of the C-MACs addresses within the Chrysolite cloud is not critical. There is no hierarchy of structure. C-MACs MUST be unique within the cloud. The cloud must also be made of contiguous switches that understand the Global/Local bit in the Ethernet header, and not contain directly connected hosts, unless via an Chrysolite switch capable of performing the required MAT translation. Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 6] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 8. Packet types 8.1. 'Unknown' Packets This architecture does not have unknown packets. All MAC addresses are known in the cloud, and are found via the 'C' portion of the N- MAC addresses in much the same way that an IP packet's destination can be located within a cloud. 8.2. Native MAC Multicast ingress Packets 8.2.1. 'Reserved' multicast C and N components Multicast packets as defined by IANA; OUI = 01-80-C2, 01-00-5E, 00- 005E, and 33-33-FF MUST be either MAT translated or discarded 9. Broadcast 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 C-MACs using the address FX-FF-FF-FF-FF-FF, where X; (0x3) represents the 4 least significant bits of the most significant byte. The group bit is set and the local bit is always set for a broadcast packet within a Chrysolite network. o Bit 4 = '*'reserved o Bit 3 = 'R' Routing bit NOT set for a broadcast packet o Bit 2 = Global/Local bit MUST be set for all packets o Bit 1 = Group bit. 9.1.1. Reverse Path forwarding RPF checking is done on all broadcast packets. Packets failing this check are discarded. 10. Routing Considerations Ospf-lite will be used as the routing protocol to create pair-wise shortest paths between the C-MACs of the Chrysolite switches. 10.1. MAC address for MAC level ospf-lite MAC level communication of ospf-lite will be used, using the highest N-MAC address of the 'broadcast' C-MAC; FX-FF-FF with the group bit, Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 7] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 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.) The routing bit is shown in Fig 1. This informs the Chrysolite switch that the packet is an ospf-lite routing packet. The source address MUST be the C-MAC of the Chrysolite switch sending the ospf-lite packet. Ospf-lite routing protocol packets will only transition one Chrysolite switch hop. VLAN information about each Chrysolite switch is not required to be attached to the router LSA and SHOULD NOT be attached. Router LSAs SHOULD ONLY detail directly attached neighbor's C-MACs. The Chrysolite switch forming the LSA will use its C-MACs as the router ID. 11. How to build a Chrysolite network The Chrysolite network is a network of Ethernet switches implemented over the WAN. Each switch is given a unique MAC address called a C- MAC. These C-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 geographically closest switches they would like to connect between are decided upon. A unique VLAN number for the customer's P2P circuit is assigned sequentially from the 2^24 bit range and dedicated to this 'circuit'/ 'VLAN' 'P2P VLAN' etc. (depending on your naming convention). This VLAN number ACTUALLY builds the endpoint destination N-MAC addresses that the customers will use to communicate. The 3-octet VLAN number is added to the switch's unique first three octets of C- MAC, to build the full 6-octet N-MAC as discussed. ALL Packets entering the Chrysolite cloud are sent from the source N- MAC (built as a combination of the switch's unique 3 octets of C-MAC and the unique 3 octets of circuit N-MAC), across the cloud to the destination N-MAC (which is also built with the destination C-MAC as the first three octets and the same 3 octet circuit number). Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 8] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 12. Why are there only 2 N-MACs per VLAN? Although BB technologies regularly refer to 'customer VLANs', it is unlikely that a customer would fully bridge their real VLAN wide area. A modern LAN of 1 Gb/s 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 PC's cross Wide Area is not the meaning of 'customer VLAN'. As such when we refer to 'customer VLAN' we are assuming that a router device has terminated the 'real' customer VLANs with the associated ARPS and is actually using specific 'customer VLANs' for routing the relevant traffic over the WAN. With this understanding Chrysolite allows an N-MAC at each end of the tunnel, and provides router P2P VLAN connections. 13. OAM System management can take place if IP addresses are configured. An OAM system can work in conjunction with SNMP to ascertain and configure unique N-MACs. A MIB will be produced for Chrysolite switches, with variables for P2P VLANs (N-MACs) assigned. 14. An example operation (How the MAT 'backup' works and why) Consider figure 2 below. The routers attached at each end of the P2P Chrysolite cloud see their network as it is, a MAC-to-MAC connection. The routers may have IP addresses and these should be in the same network as per normal router-to-router communication. When not using UNI If the routers are not using the UNI and are ignoring the UNI packets being sent from the Chrysolite switch, then they may ARP for the remote end's layer three address. Assuming IP, this will work as follows: R1 (1.1.1.1) ARPs for R2 (1.1.1.2). The ARP is sent into the ingress Chrysolite switch (C1) which performs the required MAT to the known destination N-MAC address. It is known because the VLAN number (N portion of the MAC) has been selected to be unique for this 'circuit' and the circuit endpoint (the C-MAC portion)is the physical location purchased by the customer. Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 9] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 When the packet arrives at the egress of the Chrysolite cloud (C2) the packet is MAT translated to the ARP broadcast MAC address, with the source left untranslated. Thus the end router R2, sees the N-MAC of R1 as a source MAC and will use it to reply to R1. The same conversion takes place on the ARP reply, with R2s source address being MAT, resulting in each of the two routers R1 and R2 knowing the correct translated N-MAC of the other end. Once this initial IP ARP takes place, the destination MAC addresses should be the correct destination N-MAC. MAT is removed from the destination N-MACs and only applies to the source N-MACs. Until the ARP times-out, the routers know the destination N-MACs and the Chrysolite ingress switches only have to MAT the source MAC to the required N-MAC. When using the UNI When UNI is activated at the router ends then MAT is not required, as the routers can form the packets correctly when building the MAC frames with the correct N-MACs required to travel over the Chrysolite cloud. ALL packets sent by the router over the P2P connection MUST be constructed using these addresses including any multicast MACs, special frames etc. If the router does not do this, then the Chrysolite switch must either MAT translate the unusual packet arriving at the ingress interface OR discard the packet and not propagate it further into the Chrysolite network. Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 10] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 Fig. 2 Without and with UNI Example +-----------------------------------------------------------+ | Without UNI in operation | | +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+ +-+-+ +-+-+ +-+-+ | | | R1|--------|C1 |--Chrysolite-----|C2 |------| R2| | | +-+-+ +-+-+ switches +-+-+ +-+-+ | | H1 H2 H3 | | | | ARP request over P2P VLAN Circuit | | ---------------------------------- | | Header 1 (H1) SA=R1, DA=ARP | | Header 2 (H2) SA=R1-N-MAC, DA=R2-N-MAC source MAT | | Header 3 (H3) SA=R1-N-MAC, DA=ARP dest MAT | | | | ARP reply | | --------- | | Header 3 (H3) SA=R2, DA=R1-N-MAC | | Header 2 (H2) SA=R2-N-MAC, DA=R1-N-MAC source MAT | | Header 1 (H1) SA=R2-N-MAC, DA=R1 dest MAT | | | | | | With UNI in operation | | +-+-+-+-+-+-+-+-+-+-+- | | | | +-+-+ +-+-+ +-+-+ +-+-+ | | | R1|--------|C1 |--Chrysolite-----|C2 |------| R2| | | +-+-+ +-+-+ switches +-+-+ +-+-+ | | H2 H2 H2 | | | | | | All packets from R1>R2 (including ARPS) | | --------------------------------------- | | Header 2 (H2) SA=R1-N-MAC, DA=R2-N-MAC | | | | All packets from R2>R1(including ARPS) | | --------------------------------------- | | Header 2 (H2) SA=R2-N-MAC, DA=R1-N-MAC | | | +-----------------------------------------------------------+ Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 11] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 15. Security Considerations The use of Chrysolite in a Backbone Bridging network presupposes specialist switching equipment and dedicated circuits. Hosts cannot connect directly to such a network without an Chrysolite switch. As such this draft does not introduce security elements not already present in Backbone bridging environments, and due to the backup MAT or discard process it may mitigate some issues. 16. IANA Considerations Chrysolite UNI will require an Ethernet code point [TBD], and a reserved multicast MAC addresss. A MIB will also be required for the Chrysolite switches. 17. Conclusions This architecture provides pair-wise shortest paths to backbone bridges. This is accomplished via the use of MAT and Chrysolite UNI. 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 [LITE] Thomas, M., Hunter, D., Reed, M., "ospf-lite", Internet Draft (expired) draft-thomas-hunter-reed-ospf-lite-00.txt August 2007. 18.2. Informative References [FINN] Finn, N., Provider Bridge Layer Two Protocols", IEEE 802.1 work in progress, March 2003 Yousuf Thomas Hunter Expires Sept 21, 2008 [Page 12] Internet-Draft Chrysolite - a backbone bridging solution Mar 2008 Author's Addresses Mohammad A Yousuf CES Department University of Essex Colchester CO4 3SQ Email: mayous@essex.ac.uk Matthew R Thomas CES Department University of Essex Colchester CO4 3SQ 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 Sept 21, 2008 [Page 13] Internet-Draft Chrysolite - a backbone bridging solution Mar 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 Sept 21, 2008 [Page 14]