INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 CCAMP Working Group Internet Draft T. Kawakami Document: draft-kawakami-vlan-lsp-signalling-00.txt G. Velev Matsushita N. Ogashiwa JAIST H. Ogawa CRL Expires: December 2003 June 2003 Method to Set up LSP using VLAN Tag Switching 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. Abstract This document describes a method to set up a Layer 2 tunnel over Ethernet-based networks. For this purpose, the ports of an Ethernet switch are configured to forward VLAN tag-labeled frames incoming from a certain port to another unambiguous port by using only the VLAN tag information. The Ethernet switches form the transport plane and are a part of Label Switching Routers (LSRs). In the control plane the VLAN tags are distribute using Label Distribution Protocol (LDP) and Resource Reservation Protocol-Traffic Engineering (RSVP- TE). To enable LDP and RSVP-TE to fulfil that function, this document proposes extensions in these protocols. The introduced method simplifies the control and management of wide area Ethernet networks and limits the distribution of broadcast/multicast frames. Expires - December 2003 [Page 1] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 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]. Table of Contents 1. Introduction..................................................2 1.1 Motivation...............................................3 1.2 Network Architecture.....................................4 2. Definitions...................................................5 3. VLAN Tag Switching (Forwarding Plane).........................7 3.1 Forwarding Component of Edge VLAN-LSR....................8 3.2 Forwarding Component of internal VLAN-LSR................8 4. Encapsulation.................................................8 5. Label Distribution and Maintenance (Control Plane)...........10 5.1 Control Component of Edge VLAN-LSR......................10 5.2 Control Component of Internal VLAN-LSR..................11 6. LDP Extension with new VLAN Label TLV........................13 7. RSVP-TE Extension............................................14 7.1 Label Object............................................15 7.2 Label Request Object....................................15 7.3 Sender Template Object..................................16 8. IANA Considerations..........................................17 9. Security Considerations......................................17 10. Intellectual Property Considerations.........................18 11. References...................................................18 12. AuthorĘs Addresses...........................................19 13. Full Copyright statement.....................................20 1. Introduction In this document, a method is presented that automatically sets up Layer 2 (L2) tunnel through Ethernet switches. At the tunnel ingress point the packets are labeled with VLAN tag(s), as defined in [5], and the forwarding through the Ethernet switches is done according to the VLAN tag value. The Ethernet switches on the other hand are merely one part of the Label Switching Routers (LSRs). To set up a L2 tunnel, also called VLAN Label Switch Path (VLAN-LSP) in this document, the VLAN tags are distributed throughout Label Switched Routers (LSRs). The main purpose of this document is to propose extensions of the signalling protocols in order to enable establishing and maintaining of L2 tunnels by distributing VLAN tags. In particular extensions of (1) LDP to set up hop-by-hop tunnels and (2) RSVP-TE to use the advantages of explicit routing are proposed. Expires - December 2003 [Page 2] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 Further, Section 1 describes the motivation of developing a new transport method over VLAN-aware Ethernet switches and presents the architecture of the network. Section 2 specifies some terms of the used terminology. Sections 3, 4 and 5 describe the characteristics of the LSRs as well as of the LSP management. Sections 6 and 7 provide the main contribution of this document - definition of new label TLV in the LDP protocol and new objects in the RSVP-TE protocol. 1.1 Motivation The Ethernet technology is widely deployed for Local Area Networks (LAN) since couple of years. Recently, due to appearance of high- speed, long distance and broadband Ethernet technology, Ethernet is applied to Metropolitan Area Networks (MAN) and Wide Area Networks (WAN) as well. In this document, the use of Ethernet in MAN/WAN networks is described as wide area Ethernet. One application gaining more importance in the last time is the employment of Ethernet by service provider in the access network, e.g. connecting (1) a subscriber and an Internet Service Provider (ISP) or (2) several private LANs. The extension of L1/L2 Ethernet services to be provided in the access network is a subject of [11]. However, some problems occur when LAN-Ethernet is extended to wide area Ethernet. First, the provider equipment should manage a great number of users, which would result in hardly scalable network. Second, it is necessary to limit the distribution of the broadcast packets generated by the users in order to avoid the undesirable flooding. To avoid these disadvantages we propose a simple solution for point-to-point tunnelling of Ethernet packets over wide area Ethernet networks, assuring that all packets between the two entities follow the same predetermined path. Our method is based on the use of VLAN tags as labels, which determine unambiguous the outgoing port of all Ethernet switches along the path. There are ongoing standardisation activities in [10] aiming to extend existing Ethernet protocols for better performance in wide area Ethernet, which include distributed control and management. Unlike to this approaches, the method proposed in this document employs GMPLS control protocols (LDP and RSVP-TE) for signalling the information needed to configure the switching equipment. Basically VLAN networks, as introduced in [5], use the concept of building groups of users, which are placed in different network domains, in such order that the broadcast traffic is exchanged only between the members of the group. If this concept is applied for the method proposed in this document, a group between two entities (e.g. Expires - December 2003 [Page 3] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 subscriber and ISP or LAN-LAN connection) is formed, and thus, all the traffic generated by these entities is distributed only between them. This method can be generically called a "set up of LSP over Ethernet using VLAN tag switching", where the LSP is understood as a point-to-point path between two entities. Introducing this method the high-speed and broadband network services between a user and an ISP can be achieved economically. 1.2 Network Architecture The proposed method of setting up LSP over Ethernet using VLAN tag switching can be realised as one network, in which the information is transported in two independent planes. In this document they are referred as forwarding plane and control plane. The forwarding plane assures the reliable L2 switching of data packets over network and uses the forwarding component of VLAN-LSR (a definition of VLAN-LSR is given in Section 2). The control plane deals with the LSP setting and management, as either LDP or RSVP-TE are used for label distribution. Further a network management entity, called Network Manager, calculates the paths (VLAN-LSP) and it can control the network load. Note that the Network Manager is needed only if RSVP-TE is used for label distribution. +---------+ | Network | | | Manager | | +---------+ +----------+ | | | /-| VLAN LSR |-\ | | +----------+ / +----------+ \ +----------+ | | | Edge |---/ \...---| Edge | | <-->| VLAN LSR | | VLAN LSR |<--> another | +----------+ +----------+ | network | |<-------- VLAN-LSP --------->| | |<----------------- VLAN-LSR domain -------------------->| Figure 1: Overview of a VLAN-LSR network Forwarding plane: A standard VLAN-aware Ethernet switch is used as a forwarding component of the VLAN-LSR, and thus, the MAC address and the VLAN tag are used for the data packet switching. However, applying the method proposed in this document, the switching is determined by the VLAN tag applied at the ingress node of the L2 tunnel. Therefore the VLAN tag is referred as a label and the data path can be called LSP or more precisely VLAN-LSP as defined in Section 2. Expires - December 2003 [Page 4] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 The control plane does the configuration of the forwarding plane automatically. More detailed description of the functions and characteristics in the forwarding plane is given in Section 3. Control plane: The VLAN-LSP setting and management is done in the control plane by the control component of VLAN-LSR. The VLAN-LSP setting can be achieved in two ways: explicit path for traffic engineering, (using RSVP-TE) and hop-by-hop setting (using standard LDP). The control (i.e. LDP or RSVP-TE) packets are processed by Layer 3 in the control component of the VLAN-LSR. Each control component of VLAN-LSR has at least 1 IP address, which is used for routing the control packets. More detailed description of the procedures in the control plane is given in Section 5. The label distribution technique described here is referred according to [3] as downstream on demand with ordered control. Using a standard Ethernet switch as a forwarding component leads to two main differences to the MPLS concept: - the label-switching is not performed using only one label but using MAC address and VLAN tag; - label swapping at the LSR cannot be performed. With respect to other characteristics of the generic MPLS idea, the proposed method could be observed as implementing MPLS concept over Ethernet. For instance, the transmission is executed in L2, so it depends on neither the network layer protocol nor the address system. Further, by managing VLAN-LSP configuration aggregately, the path can be configured and managed freely in order to perform traffic engineering. VLAN-LSP could find a broad application from Carriers and ISPs, the networks of which are based on wide area Ethernet technology, as for instance, a connection between user and ISP or a L2VPN over an Ethernet access network. 2. Definitions A LSR is a device which implements the label switching control and forwarding component described in [3]. A VLAN-LSR is an LSR with a number of Ethernet interfaces, which forwards frames between these interfaces, using labels carried in the VLAN tag. The structure of the VLAN-LSR is depicted in Figure 2. Expires - December 2003 [Page 5] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 Control packets (e.g. LDP or RSVP-TE messages) are distributed using L3 routing, which is performed by the VLAN-LSRs. A VLAN-LSR domain is a set of VLAN-LSRs which are mutually interconnected by Ethernet interfaces. An Edge VLAN-LSR is a VLAN-LSR that connects the VLAN-LSR domain with a node, which is outside of the domain. +-----------------------------+ | +-----------------------+ | | | Control Component | | | +-----------o-----------+ | | | Control Interface | +-----------o-----------+ | | | Forwarding Component | | | | (Ethernet Switch) | | | +--o--o--o--o--o--o--o--+ | +-----+--+--+--+--+--+--+-----+ | | | | | | | Ethernet Interface Figure 2: Structure of a VLAN-LSR Ethernet interface is a standard Ethernet interface used to transport data and control packets. The control interface connects control component and forwarding component. Transport of control (LDP or RSVP-TE) packets and configuration of the forwarding plane are performed over this interface. The control interface can consist of several logical and/or physical interfaces. Forwarding component is a VLAN-aware Ethernet switch. Its ports can be configured automatically through the control interface. Forwarding component performs label switching, which is accomplished by using the label value to forward packets. Control component is a device implementing the LDP, resp. RSVP-TE, protocol and performing IP routing. After receiving and analysing a label distribution (LDP/RSVP-TE) packet, the control component generates a new label distribution packet and configures the ports of the forwarding component through the control interface. VLAN-LSP is a path through one or more forwarding components of VLAN- LSRs that is followed by VLAN tag labeled packets. Since the label- switched path (LSP) is completely defined by the VLAN tag applied at the ingress edge VLAN-LSR and no label swapping function is Expires - December 2003 [Page 6] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 performed, the VLAN-LSP can be treated as tunnel. When a VLAN-LSP is used in this way, we refer to it as bi-directional. Employing VLAN tag switching, the label is carried in the VID field of the VLAN tag (see Section 4). Since the forwarding component should distinguish between control and data packets, it is necessary to introduce two types of VLAN tags: control and forwarding tag. They are classified according the VID value. Control tag is a VLAN tag, the VID value of which is in a certain range configured by the network operator. The range of VID values of the control tag can be configured freely, as long as there is no overlap with the forwarding tag values. The control tag is used for switching of control packets, i.e. routing packets or LDP/RSVP-TE packets. Forwarding tag is a VLAN tag, the VID value of which is not in the range of the control tag values. The forwarding tag is used for switching the data packets over the Ethernet interface. In addition, this document uses the terminology defined in [3]. 3. VLAN Tag Switching (Forwarding Plane) The task of the forwarding plane is to transport the data packets along a VLAN-LSP between two Edge VLAN-LSRs. This transport is achieved through VLAN tag switching in the forwarding component of the VLAN-LSR. According to the functionality of the forwarding component, it can be classified in 2 groups: forwarding component of edge VLAN-LSR and forwarding component of internal VLAN-LSR. Comparing the method proposed in this document and the MPLS concept, some differences can be highlighted. This document does not specify the following cases: - point-to-multipoint and multipoint-to-point LSPs; - the LSRs use LSP merge. However, some opportunities to specify the above cases exist and could be a subject of future works. Using a standard VLAN tag as label, no Time-to-Live (TTL) counter is supported in the Layer 2 header. Such TTL counter is present merely in the IP header, which is not manipulated by the forwarding component, and therefore, "TTL-decrement" function cannot be supported in the forwarding plane. An option to support "TTL- decrement" function could be found in Section 4. Expires - December 2003 [Page 7] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 3.1 Forwarding Component of Edge VLAN-LSR By receiving a data packet, the forwarding component of ingress edge VLAN-LSR assigns this packet to a VLAN-LSP and inserts a VLAN tag with VID corresponding to VLAN-LSP Identifier (LSPID) in the Ethernet header as it is shown in Section 4. Then, the labeled packet is switched based on the VID to a port corresponding to this VID. When the labeled packet arrives at the egress edge VLAN-LSR, it is switched to the corresponding port and the VLAN tag is removed before the packet leaves the VLAN-LSR domain. 3.2 Forwarding Component of internal VLAN-LSR The forwarding component analyses the VID of the incoming labeled data packets. Depending on the value of the VID, the packet is switched to a port belonging to the LSP ID of the packet. While the MPLS architecture permits considerable flexibility in LSR implementation, a VLAN-LSR is constrained by the capabilities of the pre-existing hardware and the restrictions of the VLAN tag format as defined in [5]. Since the forwarding component is a VLAN-aware Ethernet switch, the VID field of the labeled packet remains unchanged on the whole VLAN-LSP, and therefore, the label swapping function cannot be performed. 4. Encapsulation The procedures described in this section affect only the Edge VLAN- LSRs. The internal VLAN-LSRs themselves do not modify the encapsulation in any way. The description of the encapsulation in this section is fully conformant with the encapsulation proposed in [5]. Expires - December 2003 [Page 8] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPID 0x8100 | Pri | | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-Type 0x0800 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Network Layer Packet (IP packet) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ethernet destination/source address: Address of the data link layer defined by IEEE802.3. TPID: Tag Protocol Identifier = 0x8100 Pri: User Priority (3 bits) CFI: Canonical Format Indicator (bit #19 in VLAN tag) = 0 VID: Virtual LAN Identifier (12 bits) TCI: Tag Control Information (16 bits - Pri+CFI+VID) E-Type: Ethernet payload type (16 bits) ū 0x0800 for IP payload The VLAN tag consists of TPID field (0x8100), which identifies the VLAN tag, and TCI field, which contains the control information. The label value is encoded into the VID field. Having a 12 bit VID field, 4096 different labels are available, but since some of the labels are reserved, about 4000 VLAN-LSPs could be set over the VLAN- LSR domain. To increase the number of connections over the VLAN-LSR domain, VLAN tag stacking could be proposed, as the upper VLAN tag is used for the packet switching (performing VLAN-LSP) and the lower VLAN tag is used for mapping several connections over one VLAN-LPS. However, the standardisation of VLAN tag stacking is not in the responsibility of IETF. Using a standard VLAN tag as label, no TTL filed is present in the Layer 2 header, and therefore, "TTL-decrement" function cannot be supported in the forwarding plane, i.e. along the VLAN-LSP. However, such TTL counter is available in the IP header, which is not manipulated by the forwarding component, but using the hop count option as defined in [6] and [9], the "TTL decrement" function could be performed in the egress edge VLAN-LSR. Expires - December 2003 [Page 9] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 The Pri field in VLAN tag identifies the user priority of the packet and could be used similarly as Exp field described in [4]. 5. Label Distribution and Maintenance (Control Plane) In this section, primarily label allocation, distribution, and maintenance procedures are described. These procedures are performed by the control component of the VLAN-LSR. In general, label distribution is done by a number of different mechanisms, notably the LDP [6], Border Gateway Protocol (BGP), and RSVP-TE [10]. In this document, it is assumed that the label bindings are distributed only by LDP and/or RSVP-TE. Below, certain requirements on these two protocols are described. A support of VLAN tag switching does NOT require from the VLAN-LSR to support the VLAN control component defined by the IEEE (e.g., STP, GARPI). This document discusses the use of "downstream-on-demand with ordered control" label distribution (see [6]) by VLAN-LSRs. These label distribution procedures MUST be used in the control component of VLAN-LSR. First we describe the behaviour of the control component of the edge VLAN-LSR and afterwards of the internal VLAN-LSR. 5.1 Control Component of Edge VLAN-LSR A VLAN-LSP MUST be configured by the control components of all VLAN- LSRs along the path before starting to forward data packets. For this purpose, the Network Manager (see Figure 1) calculates the VLAN-LSP and the further steps for setting up the VLAN-LSP depend on the used signalling protocol. If LDP is used, the Network Manager (NM) sends to the ingress LSR the IP address of the egress VLAN-LSR. Afterwards the VLAN-LSP can be set up employing the routing tables of the VLAN- LSRs and knowing the IP address of the egress VLAN-LSR. On the other hand, if RSVP-TE with EXPLICIT_ROUTE object (ERO) is used, the NM sends a list of IP addresses to the ingress edge VLAN-LSR. This list contains the IP addresses of the control components of all VLAN-LSRs, which construct the path. The ingress edge VLAN-LSR uses RSVP-TE signalling protocol to send Path message with LABEL_REQUEST and EXPLICIT_ROUTE objects to the VLAN-LSR having the next IP address in the ERO. Once the control component of the edge VLAN-LSR receives the Label Mapping Message (LDP)/Resv Message (RSVP-TE), it configures the forwarding component. To forward data packets along a VLAN-LSP, the forwarding component of ingress VLAN-LSR SHOULD insert a VLAN tag in the Ethernet header. Respectively, the egress VLAN-LSR SHOULD forward Expires - December 2003 [Page 10] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 the packet according to the VID and remove the VLAN tag before the packet leave the VLAN-LSR domain. There are two possibilities to decide how to determine the VLAN tag: (1) Using RSVP-TE The use of RSVP-TE offers another two possibilities to determine the VLAN tag to be inserted in the incoming data packets. It depends which message type is used for signalling the VID: - If the Path message is used, then the VID for the VLAN tag is derived from SENDER_TEMPLATE object using its "LSP ID" field. More precisely, the "LSP ID" field has length of 16 bit, while the VID field is only 12-bit long, and therefore, the VID is encoded right justified in bits 20-31 (see section 7.3). Having this in mind, the network management system (i.e. Network Manager) sets the "LSP ID" field in such manner that the last 12 bits of this field are a unique identifier of the VLAN-LSP connection for the whole VLAN-LSR domain. - If the Resv message is employed, then the control component may use the LABEL object to determine the VID for the VLAN tag. In this case the VID is encoded right justified in bits 20-31 as defined in section 7.1. (2) Using LDP Since no unambiguous VLAN-LSP identificator (like "LSP-ID") is available, only the egress VLAN-LSR MUST determine the VID value in the VLAN tag.. Thus, in order to avoid overlapping of the VID values because a number of egress VLAN-LSRs can be present in the network, each egress VLAN-LSRs should require that value from the Network Manager. The Network Manager distributes the VID value to the egress VLAN-LSR using a newly specified "VLAN Label TLV" (see section 6) in the Label Mapping Message. To achieve the data forwarding along a certain VALN-LSP, the control component configures the forwarding component (i.e. Ethernet switch) as sending to it information for data packet classification, which includes input port number, VID value of the VLAN tag and output port number. Since the VLAN-LSP is bi-directional, the edge VLAN-LSRs of a given VLAN-LSP perform the functions of both ingress and egress LSR. 5.2 Control Component of Internal VLAN-LSR The functionalities of the control component of an internal VLAN-LSR depend on the used signalling protocol. Below the procedures for RSVP-TE and LDP are described. Expires - December 2003 [Page 11] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 5.2.1 Using RSVP-TE It is assumed that the RSVP-TE signalling is used together with explicit routing, which means with ERO object. When an internal VLAN- LSR receives a Path Message for a certain VLAN-LSP from a connected peer, it takes the following actions: 1. it allocates a label (VID) from the "LSP ID" field of SENDER_TEMPLATE object. This means if the bits 20-31 of the "LSP ID" field are set, then the control component configures the input port of the forwarding component binding that port with the VID value. 2. it sends a request to the next VLAN-LSR. That means a Path Message with LABEL_REQUEST object and SENDER_TEMPLATE object is send to the VLAN-LSR with next IP address from the ERO. 3. after a Resv message is received from the downstream VLAN-LSR and the LABEL object is present, the control component configures the correspondent port of the forwarding component with the VID value. Whenever a VLAN-LSR originates a Path Message to its downstream LSR as a result of receiving a Path Message from another (upstream) LSR, and the request is not satisfied, the VLAN-LSR SHOULD destroy the binding created in response to the received request, and notify its requester. 5.2.2 Using LDP If LDP is used as signalling protocol, it MUST be configured in ingress-initiated downstream-on-demand with ordered control label distribution mode (as defined in [3] and [6]). The label for the VLAN-LSP (i.e. the VID) is distributed from the egress VLAN-LSR to the ingress VLAN-LSR. Therefore, a Label Request Message is send consequently from the ingress VLAN-LSR to the egress VLAN-LSR through the internal VLAN-LSRs in hop-by-hop basis. When an internal VLAN-LSR receives a Label Request Message, it takes the following actions: 1. it sends a Label Request Message to the next downstream VLAN-LSR. 2. subsequently to the request, it receives a Label Mapping Message from the downstream VLAN-LSR, which contains the "VLAN Label TLV" proposed in section 6. Then the control component allocates a label (VID) determined from the VLAN Label TLV's VID field and configures the forwarding component. Expires - December 2003 [Page 12] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 3. it returns a Label Mapping Message back to upstream VLAN-LSR peer that originated the initial request. Note: When two VLAN-LSPs are completely separated in the domain (two LSPs never passes the same VLAN-LSR), as long as managing with the network management function, the same label (first 12 bits of "LSP ID" field of SENDER_TEMPLATE object) MAY be used for these two VLAN- LSPs. Whenever a VLAN-LSR originates a Label Request Message to its next hop LSR as a result of receiving a Label Request Message from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the VLAN-LSR SHOULD destroy the binding created in response to the received request, and notify the requester. When a VLAN-LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. For any label bindings that were created as a result of receiving Label Request Message from the peer, the LSR MAY destroy these bindings (and release labels associated with these binding). 6. LDP Extension with new VLAN Label TLV In this section, a LDP extension is proposed in order to enable the control components of VLAN-LSRs to communicate the necessary information to set up VLAN-LSP. This LDP extension includes the definition of a new Label TLV, called VLAN Label TLV, which is distributed by the Label Mapping Message. Applying the VID field of VLAN tag as a label for switching in the forwarding plane, the forwarding component must be correspondingly configured by the control component in the VLAN-LSR. Since the communication between the control components is performed by LDP, it is REQUIRED that the VID information is encoded in the LDP packets. To achieve this requirement, the VLAN Label TLV is specified as follows: Expires - December 2003 [Page 13] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| VLAN Label (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Should be set to 0 as well as in all other Label TLVs. F bit Should be set to 0 as well as in all other Label TLVs. VLAN Label This field indicates that the label type is the VLAN Label TLV. We suggest the value 0x0203 for this label type, which has to be assigned by IANA. Length Specifies the length of the Value field in octets. Reserved This field is reserved. It should be set to zero on transmission and ignored on receipt. VID Virtual LAN Identifier (12bit). This field is the same as the VID field of VLAN tag specified in 802.11q [5]. In the control component, the handling of the VLAN label TLV in the included in the Label Mapping Message is described in Section 5. 7. RSVP-TE Extension In this section, RSVP-TE extensions are proposed in order to enable the control components of VLAN-LSRs to communicate the necessary information to set up VLAN-LSP. These RSVP-TE extensions include the extensions for VLAN tag in the LABEL and LABEL_REQUEST objects. Further, a definition for the "LSP" ID field in the SENDER_TEMPLATE abject is provided in Section 7.3. As it is specified in [9] Section 3.1, both SENDER_TEMPLATE object and LABEL_REQUEST object should be presented in the Path message. Expires - December 2003 [Page 14] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 7.1 Label Object The format of the LABEL object is as defined in [9] Section 4.1: LABEL class = 16, C_Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ( top label ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The content of a LABEL is a single label, encoded in 4 octets. To allow the transport of VLAN tag's VID, which has the length of 12 bits, the VID is encoded right justified in bits 20-31. The preceding bits 0-19 should be set to zero on transmission and ignored on receipt. In the control component of the VLAN-LSR, the handling of the VID encoded in the LABEL object on receipt of Resv message is described in Section 5. 7.2 Label Request Object The Label Request Class is 19 as defined in [9] Section 4.2. Currently there are three possible C_types. We would like to define a new C_Type = 4, which is a label request with a VLAN tag label range. The LABEL_REQUEST object with a VLAN tag label range format is shown below: Class = 19 , C_Type = 4 (actually, will be allocated by IANA) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Minimum VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Maximum VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt. Expires - December 2003 [Page 15] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 L3PID an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. Minimum VID This 12-bit field specifies the lower bound of a block of VLAN ID that is supported on the originating switch. Maximum VID This 12-bit field specifies the upper bound of a block of VLAN ID that is supported on the originating switch. 7.3 Sender Template Object The SENDER_TEMPLATE object might have two different formats depending of the IP version as defined in [9] Section 4.6.2. In both cases the "LSP ID" field is 16 bits long. The 12 bits long VLAN tag's VID is encoded right justified in bits 20-31. The preceding bits 16- 19 should be set to zero on transmission and ignored on receipt. The formats of the SENDER_TEMPLATE object are shown below: 1) Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 tunnel sender address IPv4 address for a sender node LSP ID A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. Expires - December 2003 [Page 16] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 2) Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 tunnel sender address IPv6 address for a sender node LSP ID A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The handling of the VID encoded in the SENDER_TEMPLATE object's "LSP ID" field on receipt of the Path message is described in Section 5. 8. IANA Considerations Two values have to be assigned by IANA for this document: One new label type for VLAN Label TLV (suggested label type = 0x0203), which is defined in Section 6. One new RSVP C_Type for the LABEL_REQUEST object (Class = 19, suggested C_Type = 4), which is defined in Section 7.2. 9. Security Considerations The encapsulation and procedures specified in this document do not interfere in any way with the application of authentication and/or encryption to network layer packets (such as the application of IPSEC to IP diagrams) Expires - December 2003 [Page 17] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 The procedures described in this document do not protect against the alternation (either accidental or malicious) of the MPLS labels. Such alternation could cause misforwarding. The procedures described in this document do not enable a receiving VLAN-LSR to authenticate the transmitting VLAN-LSR. A discussion on the security considerations applicable to the label distribution mechanism can be found in [6]. 10. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. 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] Rosen, E., Viswanathan, A. and Callon, R., "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001 Expires - December 2003 [Page 18] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 [4] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and Conta, A., "MPLS Label Stack Encoding", RFC 3032, January 2001 [5] IEEE Std 802.1q, "Virtual Bridged Local Area Networks", December 1998 [6] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001 [7] Davie, B., Lawrance, J., McClogfrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001 [8] Conta, A., Doolan, P., and A. Mails, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001 [9] Awduche, D., Berger, L., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [10] IEEE 802.1ad Study Group, "Provider Bridges", current standard draft P802.1ad/D1, work in progress [11] IEEE 802.3ah Study Group, "Ethernet in the first mile", work in progress 12. AuthorĘs Addresses Tetsuya Kawakami Panasonic Mobile Communications Co., Ltd. Corporate Engineering Division R&D Center 600, Saedo-cho, Tsuzuki-ku Yokohama, 224-8539, Japan Phone: +81 45 939 1707 Email: kawakami.tetsu@jp.panasonic.com Genadi Velev Panasonic Multimedia Communication European Laboratories Monzastr. 4c, 63225 Langen, Germany Phone: +49 6103 766 1193 Email: velev@panasonic.de Nobuo Ogashiwa Japan Advanced Institute of Science and Technology, Expires - December 2003 [Page 19] INTERNET-DRAFT draft-kawakami-vlan-lsp-signalling-00.txt June 2003 1-1 Asahidai, Tatsunokuchi-Cho, Nomi-Gun, Ishikawa 923-1211 Japan Phone: +81 761 51 1699 ext. 1327 EMail: n-ogashi@jaist.ac.jp Hiroyo Ogawa Communications Research Laboratory Independent Administrative Institution 3-4,Hikarino-oka, Yokosuka, 239-0847, Japan Phone: +81 468 47 5070 Fax: +81 468 47 5079 E-mail: hogawa@crl.go.jp 13. Full Copyright statement Copyright (C) The Internet Society (2002). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Expires - December 2003 [Page 20]