Internet Draft MPLS Working Group Tissa Senevirathne Internet Draft Paul Billinghurst Document: draft-tsenevir-8021qmpls-01.txt Nortel Networks Category: Informational October 2000 Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks draft-tsenevir-8021qmpls-01.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 LSPs based on the P bit of the 802.1Q Tag is also a key focus of this document. Senevirathne Informational - March 2001 1 draft-tsenevir-8021qmpls-01.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 3.1. VFEC Element.....................................................4 3.2. VFEC Procedures..................................................5 3.2.1. Conservative VFEC matching.....................................6 3.2.2. Liberal VFEC matching..........................................6 4. Mapping of L2 packets to VFEC entries..............................6 4.1 Mapping of 802.1Q Tagged Packets..................................6 4.2. Mapping of non 802.1Q Tagged Packets.............................7 5. Encapsulation of Layer 2 Packets on the MPLS tunnel................7 5.1. Encapsulated Layer2 Frame data...................................7 5.2. Encapsulation of Layer 2 Packet over Frame Relay or ATM links....8 5.3. MTU Constraints..................................................8 5.4. MTU discovery on L2 paths........................................9 5.4.1. MTU Parameter TLV..............................................9 5.4.2. Use of Resource Class TLV to discover MTU Size................10 5.5. Path Establishment..............................................10 6. Fragmentations and Error Notification.............................11 7. Penultimate hop popping...........................................11 8. Use of RSVP-TE Extension to Create Layer 2 tunnels over MPLS networks.............................................................12 9. Definition of RSVP objects for Layer 2 tunnels....................12 9.1. Label Request Object............................................13 9.1.1. Label Request without Label Range.............................13 9.1.2. Label Request with ATM Label Range............................13 9.1.3. Label Request with Frame Relay Label Range....................14 9.2. Session Object..................................................15 9.2.1. LSP_LAYER2_TUNNEL_IPV4 session object.........................15 9.2.2. LSP_LAYER2_TUNNEL_IPV6 session object.........................17 10. Tspec and Flowspec object for Class-of-Service and MTU discovery.18 11. Use of POLICY_DATA object........................................19 12. Address Learning across LSP:.....................................19 13. Forwarding of IP Packets:........................................19 14. Forwarding of Broadcast and Multicast Traffic:...................20 15. Multiple LSP and out of order packets............................20 16. Alternate approach...............................................20 17. Security Considerations..........................................20 18. Acknowledgments..................................................20 22. References.......................................................20 23. Author's Addresses...............................................22 Appendix A...........................................................22 Full Copyright Statement.............................................23 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-01.txt September 2000 2. Introduction MPLS architecture, augmented with CR-LDP (constrained based label distribution) protocol [3] or RSVP-TE (Resource Reservation Protocol) [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. This document builds on the concepts discussed in [5] but focuses specifically on the delivery of Layer2 802.1Q & 802.1P based traffic. Its purpose is to provide a scalable model which allows the bundling of multiple VLAN flows into a single LSP or the granularity to provide LSPs which are built specifically to meet the TE requirements of 802.1P flows within those VLANs, by extending existing TLVs and by utilizing CR-LDP or RSVP. The concept of a "hidden" label detailing L2 parameters introduced in [5] is enhanced to meet the TE needs of 802.1P traffic classes and also to allow the specification of VLAN "ranges". This concept allows multiple VLANs logically terminating on the same egress LSR, from the MPLS perspective, to utilize the same LSP thereby optimizing MPLS resources. Forward Equivalence class (FEC) provides a mechanism for mapping incoming traffic or groups of traffic to a particular LSP. This document provides a method to implement FECs for 802.1Q VLANs and addresses the issues of transporting tagged 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 Senevirathne Informational-March 2001 3 draft-tsenevir-8021qmpls-01.txt September 2000 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 {, } We also define four different matching criteria for a VFEC entry against an incoming {TAG,P} 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 tunnel. These parameters may include the Egress LSR IP address and the Traffic Engineering (CR-LDP or RSVP-TE) parameters that characterize the tunnel. Unlike FEC entries for IP, VFEC entries, at least initially, are statically created on the ingress and egress LSRs. Dynamic discovery of extended VLAN across the MPLS network is beyond the scope of the discussion. Mapping of TAG to Egress LSR and 802.1P bits to Traffic Engineering parameters (CR-LDP or RSVP-TE) are a local policy. 3.1. 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) Senevirathne Informational-March 2001 4 draft-tsenevir-8021qmpls-01.txt September 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 3.2. VFEC Procedures Senevirathne Informational-March 2001 5 draft-tsenevir-8021qmpls-01.txt September 2000 Only the LSR with the router ID that matches the Egress LSR should decode the VFEC element. Other LSRs should transparently pass the VFEC element to the downstream LSR. If the Egress LSR cannot match the requested VFEC element, it should stop further processing and return an "unsupported VFEC" notification message. If any intermediate LSR does not support Layer 2 LSP extensions, it should stop further processing and return "unsupported Layer 2 Tunnel" notification message. Matching of VFECs may take two approaches Conservative VFEC matching Liberal VFEC matching 3.2.1. Conservative VFEC matching If F Field flag specified is for an exact match, perform the exact match. If there is no exact match, return "unsupported VFEC" notification message. The match can apply to a specific Tag or to an exact range. 3.2.2. Liberal VFEC matching If the F Field flag specified is for an exact match and matching policy specified is Liberal, allocate a label, if there is at least a match that falls into a locally supported range. 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. Senevirathne Informational-March 2001 6 draft-tsenevir-8021qmpls-01.txt September 2000 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 entries to map all MAC addresses to an appropriate LSP/FEC entry. It is therefore desirable to provide local policy/classification to map such packets to an LSP or to the appropriate FEC element. One possible mapping criterion is 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. 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/Upstream LSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC of This/Upstream 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational-March 2001 7 draft-tsenevir-8021qmpls-01.txt September 2000 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/Upstream LSR MAC address of the This/Upstream 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 2 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 Original Destination MAC address of the Layer 2 packet. Most often this is a MAC address that resides 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 LSR 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 Senevirathne Informational-March 2001 8 draft-tsenevir-8021qmpls-01.txt September 2000 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 Downstream LSR (6 bytes) + MAC of This/Upstream LSR (6 bytes) + Ether Type (2 bytes) + Size of Label (4 bytes)) P = 1482 bytes 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. At this point we propose using Experimental TLV [4] encoding to propagate an 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational-March 2001 9 draft-tsenevir-8021qmpls-01.txt September 2000 | 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, proposed Layer 2 LSP capabilities are implemented locally. F bit Forward unknown TLV bit, This bit only applies when the U bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message, if F is set (=1), the unknown TLV is forwarded with the containing message. 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 The scope of the Resource Class TLV definition may be augmented 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 Senevirathne Informational-March 2001 10 draft-tsenevir-8021qmpls-01.txt September 2000 During operation the 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, LSRs are required to perform fragmentation on packets according to the network layer protocols. However, if it is layer 2 packets that are being tunneled, LSRs should not try to interpret the network layer protocol. All packets that do not meet any MTU size requirements MUST be silently discarded. LSRs should not try to generate error notification using network layer error notification methods such as ICMP. It is therefore important that an LSR efficiently identifies whether the packet is a layer 3 routed packet or a layer 2 tunneled frame. There are two methods by which this identification may be achieved; as explained in [6], during the label resolution stage an LSR may define a local label resolution flag to indicate that the incoming label __l__ is carrying Layer 2 traffic. A LSR can easily identify that a given label request is for a layer 2 tunnel by identifying the presence of the VFEC element in the label request message. Adopting 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 LSRs could then quickly distinguish between MPLS bridged Layer 2 traffic and MPLS layer 3 routed traffic. 7. Penultimate Hop Popping It is noted that the proposed approach will not support penultimate hop popping because of the expectation for Layer 3 information to immediately follow the MPLS label as opposed to the proposed Layer 2 information. This will prevent the existing forwarding mechanisms when penultimate hop popping is employed from functioning, i.e. there is no mechanism for the Egress LSR to determine that the frame data beyond the MAC header is layer 2 data as opposed to Layer 3 and process it as such. If penultimate hop popping is a requirement it is possible to use the approach discussed in [5] which proposes using a hidden label in addition to the standard next hop label. This label may represent the larger scope of Layer 2 forwarding at the Egress LSR. This special label should be pushed on to the label stack prior to the next hop label, thus creating a multi level label stack. This may lead to more efficient forwarding at the egress LSR. Senevirathne Informational-March 2001 11 draft-tsenevir-8021qmpls-01.txt September 2000 8. Use of the 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 Specification [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] are flexible enough such that reservation can be easily achieved for Layer 2 traffic, where Layer 3 protocol, if present, is opaque across the LSP. In an MPLS environment, knowledge of Layer 3 protocol is not essential to forward a packet. Layer 2 traffic has its own limitations with regard to fragmentation when tunneled across an MPLS cloud, i.e. with the Layer 3 information encapsulated, intermediate LSRs are unable perform fragmentation. It is therefore desirable to setup LSPs with pre- determined MTU size requirements. [8] Presents a way of achieving this end to end. An egress LSR may choose to combine multiple "Layer 2" reservation requests. This may be especially useful if an egress LSR wishes to merge traffic terminating into a single VLAN from different ingress sources. Similar to [8] it is suggested that Reservation Styles, Fixed Filter (FF) and Shared Filter (SF), be used during reservation, to either explicitly allocate resources or share resources. 9. Definition of RSVP objects for Layer 2 tunnels [8] Has defined a new RSVP Object, namely the LABEL_REQUEST object. The LABEL_REQUEST object is defined to setup LSPs for Layer 3 traffic. To setup Layer 2 LSPs we define 3 new C-Types (4,5 and 6) to be transmitted as part of the Label Request object. When setting up Layer 2 traffic LSPs, as discussed earlier, the egress LSR is required to identify whether it supports the requested VLAN. In short, when setting up Layer 2 tunnels one more level of scoping is introduced. To achieve this we are proposing the introduction of two more C-types (3 and 4) to the Session Object (see section below). The new C-Types are similar to those defined in [8], except that they contain the VLAN FEC element information that Senevirathne Informational-March 2001 12 draft-tsenevir-8021qmpls-01.txt September 2000 is required to achieve the extra level of scoping beyond the egress node's IP address. The following sections present the initial definition of the suggested objects. Exact procedure of implementation is left to future discussion of this paper. 9.1. Label Request Object [8] Has defined the RSVP object LABEL_REQUEST to, request labels 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 4,5 or 6 indicates to the receiving LSR, that the request is for a Layer 2 LSP tunnel label. 9.1.1. Label Request without 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. 9.1.2. Label Request with ATM 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Res | Minimum VPI | Minimum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Maximum VPI | Maximum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. M Senevirathne Informational-March 2001 13 draft-tsenevir-8021qmpls-01.txt September 2000 Setting this bit to one indicates that the node is capable of merging in the data plane Minimum VPI (12 bits) This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero. Minimum VCI (16 bits) This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero. Maximum VPI (12 bits) This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero. Maximum VCI (16 bits) This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero. 9.1.3. Label Request with Frame Relay Label Range Class = 19 C-Type = 6 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. Minimum DLCI Senevirathne Informational-March 2001 14 draft-tsenevir-8021qmpls-01.txt September 2000 This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0. Maximum DLCI This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0. 9.2. Session Object Two new C-Types are defined to reflect the Layer 2 tunnel characteristics. 9.2.1. LSP_LAYER2_TUNNEL_IPV4 session object This Session Object is defined to identify the endpoint of the tunnel i.e. egress LSR. In addition, the LSP_LAYER2_TUNNEL_IPV4 session object carries the VLAN Forward Equivalence Class(VFEC) 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 Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID Senevirathne Informational-March 2001 15 draft-tsenevir-8021qmpls-01.txt September 2000 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. Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. 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 Senevirathne Informational-March 2001 16 draft-tsenevir-8021qmpls-01.txt September 2000 9.2.2. LSP_LAYER2_TUNNEL_IPV6 session object Class = SESSION, LSP_LAYER2_TUNNEL_IPV6 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Ipv6 Tunnel End Point Address | + (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Extended Tunnel ID | + (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |S|M| BPDU Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | Start VLAN TAG | End VLAN TAG | F | SP | EP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPV6 tunnel end point address IPV6 address of the egress node of the tunnel Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 16-byte 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. Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. S Spanning Tree flag. 1 If BPDU Tag field is valid. Otherwise ignore the BPDU Tag field. Senevirathne Informational-March 2001 17 draft-tsenevir-8021qmpls-01.txt September 2000 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 Definition of this C-Type is similar to [8] with , VLAN TAG characteristics to follow. 10. Tspec and Flowspec object for Class-of-Service and MTU discovery. We propose using these objects according to the methods explained in [8]. The definition is detailed below. 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. Senevirathne Informational-March 2001 18 draft-tsenevir-8021qmpls-01.txt September 2000 CoS The Class Of Service field allows the originator to request the needed service from the network. Mapping of Priority bits to CoS class is a local policy. Ongoing work in other WG forums may prove beneficial in defining the appropriate mappings. 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, the path may be established or not established. MTU size acceptance is entirely a local policy. 11. Use of POLICY_DATA object The 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. 12. Address Learning across LSP: Like any other traditional layer 2 device, addresses MUST be learnt across an LSP. MAC addresses are learnt against a VFEC. 13. 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, the following forwarding rules MUST be observed. If there is a matching Destination MAC address use the associated LSP or Destination MAC address. If there is no matching Destination MAC address and there is a matching VFEC use that LSP. If the packet is IP search for a matching FEC entry and use that LSP. If there are no matching FEC/VFEC entries forward or drop the packet based on local policy. Senevirathne Informational-March 2001 19 draft-tsenevir-8021qmpls-01.txt September 2000 14. Forwarding of Broadcast and Multicast Traffic: If the incoming packets are tagged, forwarding of Multicast and Broadcast traffic is similar to unicast traffic, except that there is some local policy to forward to other ports in the ingress LSR. 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. 15. 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 into the correct 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. 16. Alternate approach It is possible to encapsulate the entire Layer 2 packet as the payload of an IP packet and tunnel it from the ingress LSR to egress LSR. This method provides the advantage of using the strengths of the existing MPLS infrastructure and the IP protocol. This requires that both the ingress and egress LSRs perform Network layer functionality and appears to be less efficient. However, this is considered an agenda open for discussion. 17. Security Considerations This document does not affect the underlying security issues of MPLS. 18. Acknowledgments The ideas in this document were significantly influenced by the sighted references and on going work at the IETF. Various people have influenced the work presented in this document. Akbal Karlcut, in particular provided valuable suggestions. 22. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Senevirathne Informational-March 2001 20 draft-tsenevir-8021qmpls-01.txt September 2000 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Bilel Jamoussi et al, Constrained-Based LSP setup using LDP, Work in Progress, July 2000. 4 Anderson Loa 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 Reservation Protocol (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 21 draft-tsenevir-8021qmpls-01.txt September 2000 23. Author's Addresses Tissa Senevirathne Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95051 Phone: 408-565-2571 Email: tsenevir@nortelnetworks.com Paul Billinghurst Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95051 Phone: 408-565-2357 Email: pbilling@nortelnetworks.com Appendix A Non MPLS link (Frame Relay) ------------------- | | | | -------- | | --------- | |-------- ----------------| | | LSR | | LSR | | |------- --------------- | | -------- | | --------- | | ------------------- MPLS link In a scenario like the above diagram, 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 802.1D 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 BPDUs belonging to multiple VFECs/VLANs are forwarded across the same LSP. Since multiple VFECs can share the same LSP, BPDUs require tagging to allow correct identification and mapping into the appropriate VFEC/VLAN at the egress LSR. Each VFEC may assign a unique TAG to the BPDU (which may be different from the VLAN Tag) see earlier section relating to VFEC for details. Note that a VFEC may represent more than one VLAN. Thus a TAG BPDU may represent more than one VLAN. On this basis Layer 2 forwarding across more than one extended VLAN may be controlled by a single tagged BPDU. The BPDU TAG is encoded as part of the VFEC element TLV, in the original label request message. A BPDU tag in the incoming label Senevirathne Informational-March 2001 22 draft-tsenevir-8021qmpls-01.txt September 2000 request message creates a dynamic mapping between the 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 that 802.1D is implemented on Ingress and Egress LSRs. This will allow the Ingress and Egress LSRs to properly handle BPDUs. All the outgoing BPDUs on LSPs are tagged with the appropriate BPDU Tag that was negotiated during path setup. On the other hand, incoming BPDUs from a LSP are mapped to the appropriate VFEC entry using the BPDU Tag and the LSP ID. The method of mapping of BPDUs 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. 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 23