MPLS Working Group Tissa Senevirathne Internet Draft Nortel Networks Document: draft-tsenevir-8021qmpls-00.txt Category: Informational October 2000 Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks draft-tsenevir-8021qmpls-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents a discussion on possible methods for extending Layer 2 Virtual LANs across MPLS networks through the use of CR-LDP or RSVP. Special note is taken on extending 802.1Q Tagged VLANs across MPLS networks. A new Forward Equivalence class called VLAN Forwarding Equivalence class (VFEC) is defined. Creating traffic engineered LSP based on P bit of the 802.1Q Tag is also a key focus of this document. Senevirathne Informational - March 2001 1 draft-tsenevir-8021qmpls-00.txt September 2000 Table of Content 1. Conventions used in this document..................................2 2. Introduction.......................................................3 3. Implementation of 802.Q VLAN FEC (VFEC)............................3 4. Mapping of L2 packets to VFEC entries..............................4 4.1 Mapping of 802.1Q Tagged Packets..................................4 4.2 Mapping of non 802.1Q Tagged Packets..............................4 5. Encapsulation of Layer 2 Packets on the MPLS tunnel................4 5.1 Encapsulated Layer2 Frame data....................................5 5.2 Encapsulation of Layer 2 Packet over Frame Relay or ATM links.....6 5.3 MTU Constraints...................................................6 5.4 MTU discovery on L2 paths.........................................7 5.4.1 MTU Parameter TLV...............................................7 5.4.2 Use of Resource Class TLV to discover MTU Size..................8 5.5 Path Establishment................................................8 6. Fragmentations and Error Notification..............................8 7. Penultimate hop popping............................................9 8. VFEC Element.......................................................9 9.VFEC Procedures....................................................10 9.1 Conservative VFEC matching.......................................11 9.2 Liberal VFEC matching............................................11 10. Use of RSVP-TE Extension to Create Layer 2 tunnels over MPLS networks.............................................................11 11. Definition of RSVP objects for Layer 2 tunnels...................12 11.1. Label Request Object...........................................12 11.1.1. Label Request without Label Range............................12 11.1.2. Label Request with ATM Label Range...........................12 11.1.3. Label Request with Frame Relay Label Range...................13 11.2. Session Object.................................................13 11.2.1. LSP_LAYER2_TUNNEL_IPV4 session object........................13 11.2.2. LSP_LAYER2_TUNNEL_IPV6 session object........................14 12. Tspec and Flowspec object for Class-of-Service and MTU discovery.15 13. Use of POLICY_DATA object........................................15 14. Address Learning across LSP:.....................................15 15. Forwarding of IP Packets:........................................16 16. Forwarding of Broadcast and Multicast Traffic:...................16 17. Multiple LSP and out of order packets............................16 18. Alternate approach...............................................16 19. Implementation of 8021.D.........................................17 20. Security Considerations..........................................18 21 Acknowledgments...................................................18 22. References.......................................................18 23. Author's Addresses...............................................19 Full Copyright Statement.............................................19 1. 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 [2]. Senevirathne Informational-March 2001 2 draft-tsenevir-8021qmpls-00.txt September 2000 2. Introduction MPLS architecture, augmented with CR-LDP (constrained based label distribution) protocol [3] or RSVP [8], provides a mechanism to setup a Label switched Path (LSP) with given characteristics. With the growth of Metropolitan Area Networks (MANs), the ability to extend Layer 2 Virtual LANs (VLAN) across the MAN has become important. Forward Equivalence class (FEC) provides a mechanism of mapping incoming traffic or groups of traffic to a particular LSP. This document provides a method of implementing FEC for 802.1Q VLANs and transporting Layer 2 traffic across the MPLS cloud. It also discusses mapping of 802.1P Priority (P) bits to CR-LDP traffic engineering parameters or RSVP-TE [8] objects. MAC layer address learning issues across the MPLS cloud are also discussed. The ability to implement IEEE 802.1D[9] Spanning Tree Protocol across the MPLS cloud will allow loop prevention and this in turn allows implementations to have non-MPLS backup paths between extended VLANs. 3. Implementation of 802.Q VLAN FEC (VFEC) At present FEC is defined to map an incoming IP packet or set of packets to a LSP [4]. Currently FEC elements are defined as: Address Prefix Or Host Address We propose to extend the FEC element to include 802.1Q TAG and P bits fields. To better utilize LSPs and improve scaling we suggest a concept of TAG and P grouping. Thus VLAN FEC or VFEC may be defined as Exact TAG and P field match Range of TAG and Exact P match Exact TAG and Range of P match Range of TAG and Range of P match Matching of a VFEC provides an index to the LIB (Label Information Base), if the LSP is already setup. If the LSP is not yet setup, the VFEC provides the necessary parameters required to setup the LSP Senevirathne Informational-March 2001 3 draft-tsenevir-8021qmpls-00.txt September 2000 tunnel. These parameters may include Egress LSR IP address and the CR-LDP parameters that characterize the tunnel. Unlike FEC entries for IP, VFEC entries, at least initially, are statically created on the ingress and egress LSRs. Mapping of TAG to Egress end pint LSR and 802.1P bits to CR-LDP parameters are a local policy. In addition, for redundancy, one may choose to setup more than one LSP. 4. Mapping of L2 packets to VFEC entries 4.1 Mapping of 802.1Q Tagged Packets The mapping of L2 packets to VFEC entries MUST conform to the following rules in order to avoid any ambiguities. If there is an exact match on TAG and P bits use that entry. If there is an exact match on TAG and range match on P bits use that entry. If there is a range match on TAG and an exact match on P bits use that entry. If there is a range match on TAG and a range match on P bits use that entry. If there is no TAG mapping one MAY initiate a local policy to handle such packets. There SHOULD not be any VFEC mappings based solely on the P bit field. 4.2 Mapping of non 802.1Q Tagged Packets Due to the non-hierarchical nature of MAC addresses it is practically impossible to provide FEC entry to map all MAC addresses to appropriate LSP/FEC entry. It is therefore desirable to provide local policy/classification to map such packets to a LSP or the appropriate FEC element. One possible mapping criterion is to map a physical/logical port to a LSP or a FEC. 5. Encapsulation of Layer 2 Packets on the MPLS tunnel It is important to preserve Source and Destination MAC addresses across the LSP, to enable correct forwarding. To achieve this we propose encapsulation of the entire Layer 2 packet within the MPLS shim header. Since all forwarding of MPLS packets is based upon Label lookup, it really does not matter what protocol is carried in the actual data portion of the MPLS packet. Senevirathne Informational-March 2001 4 draft-tsenevir-8021qmpls-00.txt September 2000 5.1 Encapsulated Layer2 Frame data 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC of Downstream LSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC of Downstream LSR | MAC of This LSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC of This LSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Type | Label 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . N-1 Labels . . | Nth Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth Label | Original Dest MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Dest MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Src MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Src MAC | Remainder of the Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The use and meaning of these fields are as follows: MAC of Downstream LSR MAC address of the Downstream LSR, this address will change for each hop. MAC of This LSR MAC address of the This LSR, this address will change for each hop MPLS Type This is the ethertype proposed in [6]. It is possible this may be a new value if required to identify Layer MPLS packets against Layer 3 MPLS packets at the Media Layer. Labels: MPLS labels (1 to N) stacked as proposed in [6]. Original Dest MAC Senevirathne Informational-March 2001 5 draft-tsenevir-8021qmpls-00.txt September 2000 Original Destination MAC address of the Layer 2 packet. Most often this is a MAC address that reside across the LSP Original SRC MAC Original Source MAC address of the Layer 2 packet. This address is transferred across the LSP unchanged in order to facilitate proper address learning. Remainder of the Packet This is the remainder of the original packet, minus the original FCS (Frame Check Sum). The Egress LER is required to generate a new FCS upon de-encapsulation. However, payload of the current packet is protected by the FCS of the new Encapsulation. 5.2 Encapsulation of Layer 2 Packet over Frame Relay or ATM links It is possible to encapsulate Layer 2 frames on ATM or Frame Relay links using methods suggested in [5]. However one may choose to use encapsulation presented in section 5. Encapsulation according to 6, may be useful, if links operate in packet mode. 5.3 MTU Constraints As packets traverse the MPLS cloud or during the initial encapsulation with the proposed header, it is possible the maximum MTU size allowed by the corresponding media layer could be exceeded. It is important to consider MTU size variations. Therefore in similar fashion to [6] we propose a "Maximum initially allowed layer 2 MTU Size" parameter. This is a configurable parameter. Any packet that matches a VFEC and has a MTU size greater than the above parameter is silently discarded. When deciding on "Maximum initially allowed layer 2 MTU Size" parameter one must consider, proposed new encapsulation header size, whether packets are Tagged, maximum possible number of labels that may be present and the minimum MTU size along the path. As an example, consider a MPLS tunnel where minimum MTU size along the path is 1500 bytes. Let assume at any given time not more than one label may be present. Let say "Maximum initially allowed layer 2 MTU Size" is P. Then P = 1500bytes - (MAC of This LSR (6 bytes) + MAC of This LSR (6 bytes) + Ether Type (2 bytes) + Size of Label (4 bytes)) P = 1482 bytes Senevirathne Informational-March 2001 6 draft-tsenevir-8021qmpls-00.txt September 2000 5.4 MTU discovery on L2 paths In order to ensure potential LSPs paths meet the required MTU criteria, it may be possible to pre-determine that the proposed paths can meet the Max MTU size requirements end-to-end. Two potential mechanisms are: Use of a Dedicated MTU Discovery TLV Or Enhance the scope of the resource class TLV to discover the MTU size 5.4.1 MTU Parameter TLV Define a new TLV type to discover the MTU size during path setup time. At this point we propose to use Experimental TLV [4] encoding to propagate MTU request. Ideally there should be a separate TLV defined for this purpose if the proposed method is accepted. Encoding of MTU discovery using Experimental TLV: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type(0x3F01) | Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Experimental ID(Layer 2 MTU Discovery) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O | MTU Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. Upon receipt of an Unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; If U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist. The determination as to whether the Experimental Layer 2 MTU discovery ID is understood is based on that fact that, Layer 2 is implemented locally. F bit Forward unknown TLV bit, This bit only applies when the U bit is set and the LDP message contaning the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the contaning message, if F is set (=1), the unknown TLV is forwarded with the containing message Senevirathne Informational-March 2001 7 draft-tsenevir-8021qmpls-00.txt September 2000 Experimental ID (Layer 2 MTU Size) Suggested value - 0x00000001 O Optional Matching Flag - b'00 Exact MTU size is required on the outgoing interface - b'01 MTU Size greater or Equal is required on the outgoing interface - b'10 MTU size greater than the specified value is required on the outgoing interface MTU Size Required MTU Size in bytes 5.4.2 Use of Resource Class TLV to discover MTU Size Augment the scope of the Resource class TLV definition to include the layer 2 MTU size in addition to its more commonly defined TE parameter usage. The procedure of augmenting the resource class TLV for this purpose is implementation dependent and beyond the scope of this document. 5.5 Path Establishment During operation Path may change, due to failure for example. The MTU size across paths may be different. It is possible to prevent LSP establishment across paths which do not meet the MTU requirements by using one of the above explained methods. 6. Fragmentations and Error Notification When forwarding Layer 3 packets, upon MTU size violation, LSR are required to perform fragmentation on packets according to the network layer protocols. However, when Layer 2 packets are tunneled, LSR should not try to interpret the network Layer protocol. All packets that do not meet any MTU size requirements MUST be silently discarded. LSR should not try to generate error notification using network layer error notification methods such as ICMP. Thus, it is important LSR to efficiently identify the type of transport layer function it need to provide. This may be achieved by two means, as explained in [6], during label resolution stage, LSR may define a local label resolution flag to indicate that incoming label _-l- is carrying Layer 2 traffic. A LSR can easily identify a Senevirathne Informational-March 2001 8 draft-tsenevir-8021qmpls-00.txt September 2000 given label request is for a layer 2 tunnel by identifying the presence of the VFEC element in the label request message. Adapting this method would only allow a given LSP to carry only L2 traffic or L3 traffic not both. Alternatively, it is possible to define a new ethertype to identify MPLS layer 2 tunneled traffic. All downstream LSR can quickly distinguish MPLS bridged Layer 2 traffic against MPLS routed traffic. 7. Penultimate hop popping If there exists, a penultimate hop popping, the Egress LSR/LER may not be able to forward the packet properly. If penultimate hop popping is present it is recommended that Egress LSR/LER may enable bridging on the port the LSP tunnel is terminating. The incoming packet may then be forwarded using the Destination MAC and the VLAN Tag and/or any local policy. One may also choose to configure the network with no penultimate hop popping. The incoming Label to the Egress LSR may reflect more forwarding information. Thus this may lead to more efficient forwarding at the egress LER/LSR. Alternatively, LDP may be enhanced to carry a special label from the Egress LER/LSR, in addition to the next hop label to the ingress LSR/LER. This label may represent larger scope of Layer 2 forwarding at the Egress LSR/LER. This special label may be pushed in to the label stack before the next hop label. Thus creating a multi level label stack. Improvements in multiple label distribution may be utilized to carry such labels. 8. VFEC Element VLAN FEC (VFEC) TLV carries the FEC element required to setup the LSP to carry the Layer 2 traffic. Instead of defining a new TLV we have chosen to enhance the existing FEC TLV [4]. The VFEC element will be carried in a new FEC element type. FEC element Type Value Type name L2-VLAN 0x04 TAG, P bits and BPDU Tag, (see below) 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-VLAN (0x04)| Length |S|M| BPDU Tag | Senevirathne Informational-March 2001 9 draft-tsenevir-8021qmpls-00.txt September 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | Start VLAN TAG | End VLAN Tag | F | SP | EP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Point LSR Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Length of the fields to follow in Bytes. At present this is set to 10 (0x0A). S Spanning Tree flag is set to 1, if BPDU Tag field is valid. Otherwise ignore the BPDU Tag field. M Matching Criteria. Conservative matching if M == 1, else Liberal matching. See below for details. F Field Flag - VLAN Tag Range Match - b'00 - VLAN Tag Exact Match - b'01 - P bits range Match - b'10 - P bits Exact Match - b'11 Start VLAN Tag Starting value of the VLAN Tag End VLAN Tag End Value of the VLAN Tag. This field is ignored if F == 01 SP Starting value for P bits EP End value of P bits. This field is ignored if F == 11 9.VFEC Procedures Only the LSR with the route ID matching to the Egress LSR should decode the VFEC element. Other LSR transparently pass the VFE element to the downstream router. Senevirathne Informational-March 2001 10 draft-tsenevir-8021qmpls-00.txt September 2000 If the LSR cannot match the requested VFEC element, it should stop further processing and return "unsupported VFEC" notification message. Matching of VFEC may take two approaches, Conservative VFEC matching Liberal VFEC matching 9.1 Conservative VFEC matching If F flags specified is for exact match, perform the exact match. If there is no exact match return "unsupported VFEC" notification message. 9.2 Liberal VFEC matching If F flag is specified for exact match. Allocate a label if at least there is range match that could be supported locally. 10. Use of RSVP-TE Extension to Create Layer 2 tunnels over MPLS networks Resource Reservation Protocol [7] was designed to achieve receiver initiated setup of multicast and unicast flows, with some resource requirements. [8] Has extended the original RSVP [7] to construct on-demand label switch path across MPLS clouds. [8] Provides an extensive discussion on how traffic engineered LSP can be setup for Layer 3 traffic. Both, [7] and [8] provides resource reservation mechanisms for Layer 3 traffic such as IP. However, concepts provided in [7] is flexible enough so that reservation can be easily achieved for Layer 2 traffic, where Layer 3 protocol, if one present, is opaque across the tunnel. In MPLS environment, knowledge of Layer 3 protocol is not essential to forward a packet. Layer 2 traffic has its own limitations when tunneling. Fragmentation is one of the major issues when tunneling Layer 2 traffic. Due to the agnostic nature of the Layer 3 protocol, intermediate LSR are unable perform fragmentation. Thus it is desirable to setup the LSP with some MTU size requirement. [8] Presents a way of achieving MTU size requirement, end-to-end. Egress LSR may choose to combine different reservation requests. This may be especially useful if egress LSR wish to merge traffic coming in to a given VLAN from different ingress sources. In tern this may help scaling of non hierarchical VLAN Tags. Similar to [8] it is suggested to use Reservation Styles, Fixed Filter (FF) and Shared Filter (SF), to be used during reservation, to either explicitly allocate resources or share resources. Senevirathne Informational-March 2001 11 draft-tsenevir-8021qmpls-00.txt September 2000 Ability of RSVP [8], to setup multiple LSP to the same Egress LSR, to re-route, to detect node failures, to setup path across abstract nodes is attractive in environments where reliability is a concern or where Layer 2 tunnels are required to be setup across autonomous systems. 11. Definition of RSVP objects for Layer 2 tunnels [8] Has defined a new RSVP Object, namely LABEL_REQUEST object. LABEL_REQUEST object is defined to setup LSP for Layer 3 traffic. To setup Layer 2 LSP we define 3 new c types (3,4 and 5). When setting up Layer 2 traffic, as discussed earlier, Egress LSR is required to identify whether it supports requested VLAN. In short, when setting up Layer 2 tunnels one more level of scoping is introduced. To achieve this we have introduced two more c-types (3 and 4) to the session object (see section below). In essence new c- Types are similar to C-types defined in [8], except that new types contain VLAN FEC element information that is required to achieve extra level of scope beyond the egress node IP address. Following sections present the initial definition of the suggested objects. Exact procedure of implementation is left to future discussion on this paper. 11.1. Label Request Object [] Has defined RSVP object LABEL_REQUEST to, request Label for Layer 3 protocols. There are 3 c-Types defined to resolve labels for a Layer 3 protocol. In this discussion we add 3 more c-Types to request Layer 2 labels. The presence of C-Type 3,4,5 indicates receiving LSR, that the request is for Layer 2 LSP tunnel. 11.1.1. Label Request without Label Range Class = 19 C_Type = 3 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11.1.2. Label Request with ATM Label Range Class= 19 C_type = 4 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Must be Zero | Senevirathne Informational-March 2001 12 draft-tsenevir-8021qmpls-00.txt September 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Res | Minimum VPI | Minimum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Maximum VPI | Maximum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11.1.3. Label Request with Frame Relay Label Range Class = 19 C_Type = 5 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Must be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |DLI| Minimum DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Maximum DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11.2. Session Object Two new C-Types are defined to reflect the Layer 2 tunnel characteristics. 11.2.1. LSP_LAYER2_TUNNEL_IPV4 session object This session object is defined to identify end point of the tunnel. In addition session object carries VLAN Forward Equivalence Class information that is necessary to identify the specific VLAN at the tunnel endpoint. Class = SESSION, LSP_LAYER2_TUNNEL_IPV4 C-Type = 3 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |S|M| BPDU Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | Start VLAN TAG | End VLAN TAG | F | SP | EP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPV4 tunnel end point address IPV4 address of the egress node of the tunnel Senevirathne Informational-March 2001 13 draft-tsenevir-8021qmpls-00.txt September 2000 Tunnel ID A 16-bit identifier that used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPV4 address as a globally unique identifier. S Spanning Tree flag. 1 If BPDU Tag field is valid. Otherwise ignore the BPDU Tag field. M Matching Criteria. Conservative matching if M == 1, else Liberal matching. See above for details. F Field Flag VLAN Tag Range Match b'00 VLAN Tag Exact Match b'01 P bits range Match b'10 P bits Exact Match b'11 Start VLAN Tag Starting value of the VLAN Tag End VLAN Tag End Value of the VLAN Tag. This field is ignored if F == 01 SP Starting value for P bits EP End value of P bits. This field is ignored if F == 11 11.2.2. LSP_LAYER2_TUNNEL_IPV6 session object Class = SESSION, LSP_LAYER2_TUNNEL_IPV6 C-Type = 4 Senevirathne Informational-March 2001 14 draft-tsenevir-8021qmpls-00.txt September 2000 Definition of this C-Type is similar to [8] with , VLAN TAG characteristic follow. 12. Tspec and Flowspec object for Class-of-Service and MTU discovery. We propose to use these object according to the method explained in [8]. The same format is used both for SENDER_TSPEC object and FLOWSPEC objects, the formats are; Class-of-Service SENDER_TSPEC Object: Class =12 C-Type = 3 Class-of-Service FLOWSPEC Object Class = 9, C-Type = 3 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | CoS | Maximum Packet Size [M] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be zero on transmission and MUST be ignored on receipt. CoS The Class Of Service field allows to request the needed service from the network. Mapping of Priority bits to CoS class is a local policy. Some ideas may be borrowed from on going work at IETF forum, particularly in Differential Services area. M This parameter is set in Resv messages by the receiver based on information in arriving RSVP SENDER_TSPEC objects. For shared reservations, the smallest value received across all associated senders is used. When the object is contained in the path messages, this parameter is updated at each hop with lesser of the received value and the MTU of the outgoing interface. If the received M , either via SENDER_TSPEC or FLOWSPEC object, is smaller than the required MTU size, path may be established or not established. MTU size acceptance is entirely a local policy. 13. Use of POLICY_DATA object POLICY_DATA object may be used to further define local matching criteria of different reservation requests. As an example, one may request to terminate the PATH_MESSAGE immediately if the MTU size violation occurs during the path setup stage. 14. Address Learning across LSP: Senevirathne Informational-March 2001 15 draft-tsenevir-8021qmpls-00.txt September 2000 Like any other traditional layer 2 device, addresses MUST be learnt across the LSP. MAC addresses are learnt against the LSP ID/VLAN Tag. This allows ingress LSR/LER to perform VFEC search only for unknown MAC addresses. Hence increasing the forwarding efficiency at the ingress LSR/LER. 15. Forwarding of IP Packets: It is possible there are IP protocol packets traversing across the MPLS extended VLANs. All MPLS routers have their traditional FEC based on IP address fields [4]. To avoid erroneous forwarding, after deploying the VFEC, following forwarding rules MUST be observed. If there is a matching Destination MAC address, use that LSP or Destination. If there is a matching VFEC, use that LSP If packet is IP, search for matching FEC entry and use that LSP. If there are no matching FEC/VFEC, forward or drop the packet based on local policy. 16. Forwarding of Broadcast and Multicast Traffic: If the incoming packets are tagged, forwarding of Multicast and Broadcast traffic are similar to unicast traffic, except that there is some local policy to forward to other ports in the ingress LSR/LER. Un-tagged packets are mapped to a VFEC using some local policy. Such local policies are implementation dependent and beyond the scope of this discussion. 17. Multiple LSP and out of order packets It is possible to have more than one LSP that can carry traffic between two extended VLANs. In such an environment there should be local policies that directs Layer 2 traffic in to a proper LSP, such that all packets that matches a local policy arrives at the egress LSR in the same order. Such policies are implementation dependent and beyond the scope of this document. Special care should be taken when tunneling through abstract nodes. 18. Alternate approach It is possible to encapsulate the entire Layer 2 packet as the payload of an IP packet and tunneled from ingress LER to Egress LER. This method provides an advantage to use the strength of using the Senevirathne Informational-March 2001 16 draft-tsenevir-8021qmpls-00.txt September 2000 existing MPLS infrastructure and strength of IP protocol. This requires both ingress and egress LER to perform Network layer functionality and appears to be less efficient. However, this is considered an agenda open for discussion. 19. Implementation of 8021.D Non MPLS link (Frame Relay) ------------------- | | | | -------- | | --------- | |-------- ----------------| | | LSR | | LSR | | |------- --------------- | | -------- | | --------- | | ------------------- MPLS link In a scenario like above, one may have a dedicated path to carry layer 2 traffic and a backup path across the IP network. To avoid loop it is essential to have a protocol like IEEE 8021.D implemented. Exact implementation details of 802.1D across MPLS extended tunnels are beyond the scope of this document. However, as a synopsis one may treat a LSP as a logical port, and define the layer 2 state of the LSP according to the 802.1D specification [9]. 802.1D BPDU are forwarded across LSP. Since multiple VFEC can share the same LSP, BPDU requires tagging for correct identification against the proper VLAN/VLANs. Each VFEC may assign a unique TAG to the BPDU (which may be different from the VLAN Tag) see section earlier of VFEC. Note that a VFEC may represent more than one VLAN. Thus a TAG BPDU may represent more than one VLAN. Therefore Layer 2 forwarding across more than one extended VLAN may be controlled by a single tagged BPDU. BPDU TAG is encoded as part of the VFEC element TLV, in the original label request message. BPDU tag in the incoming label request message creates a dynamic mapping between incoming BPDU and VFEC+LSP combination. As discussed earlier, more than one VFEC can share the same LSP. Hence, in effect it is the VFEC forwarding state that is affected by incoming BPDU. In order to properly implement 802.1D Spanning Tree Protocol across the extended VLAN, it is required have 802.1D implemented on Ingress and Egress LSR. This will help Ingress and Egress LSR to properly handle BPDU. All the outgoing BPDU to LSP are tagged with the appropriate BPDU Tag that was negotiated during path setup. On the Senevirathne Informational-March 2001 17 draft-tsenevir-8021qmpls-00.txt September 2000 other hand, incoming BPDU from the LSP are mapped to the appropriate VFEC entry using BPDU Tag and the LSP ID. The method of mapping of BPDU to LSP,VFEC, as explained here, allows ingress/egress LER to control the state of extended logical ports. An extended logical port is defined here as a function of LSP Id and VFEC entry. 20. Security Considerations This document does not affect the underlying security issues of MPLS. 21 Acknowledgments The ideas in this document have significant impact from the sighted references and on going work at IETF. Various people have influence significantly to the work presented in document. Paul Billinghurst and Akbal Karlcut provided valuable suggestions. 22. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Bliel Jamoussi et al, Constrained-Based LSP setup using LDP, Work in Progress, July 2000. 4 Anderson Loal et al, LDP Specification, Work in Progress, August 2000. 5 Luca Martini et al, Transport of Layer 2 Frames over ATM, Work in Progress, September 2000 6 Eric Rosen et al, MPLS Label Stack Encoding, Work in Progress, July 2000 7 R Braden et al, Resource Reserevation Protoocl (RSVP) -- version 1 Functional Specification RFC 2205, September 1197 8 Daniel O. Awduche et al, RSVP-TE: Extension to RSVP for LSP Tunnels, Work in Progress, August 2000. 9 IEEE 802.1D IEEE Standard Specification, July 1993 10 IEEE 802.1Q IEEE Standard Specification, 1998 Senevirathne Informational-March 2001 18 23. Author's Addresses Tissa Senevirathne Nortel Networks 2305 Great America Pkwy, Santa Clara, CA 95051 Phone: 408-565-2571 Email: tsenevir@nortelntworks.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne Informational - March 2001 19 draft-tsenevir-8021qmpls-00.txt September 2000 Senevirathne Informational-March 2001 20