INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 Network Working Group Internet Draft T. Kawakami Document: draft-kawakami-mpls-lsp-vlan-00.txt G. Velev Matsushita N. Ogashiwa JAIST H. Ogawa CRL Expires: August 2003 February 2003 Method to Setup 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 setup a Layer 2 tunnel over networks based on Ethernet technology. For this purpose, the ports of an Ethernet switch are configured to forward VLAN tag-labeled packets incoming from a certain port to another unambiguous port by using VLAN tag information. The Ethernet switches themselves are a part of the Label Switching Routers (LSRs), which distribute the VLAN tags using Label Distribution Protocol (LDP). To enable LDP to fulfil this function, an LDP extension is proposed. The introduced method simplifies the transport of Ethernet frames over wide area Ethernet networks. Expires - August 2003 [Page 1] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 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.......................................3 2. Definitions....................................................5 3. VLAN Tag Switching (Forwarding Plane)..........................6 3.1 Forwarding Component of Edge VLAN-LSR......................7 3.2 Forwarding Component of internal VLAN-LSR..................7 4. Encapsulation..................................................7 5. Label Distribution and Maintenance (Control Plane).............9 5.1 Control Component of Edge VLAN-LSR.........................9 5.2 Control Component of Internal VLAN-LSR....................10 6. LDP Extension with new VLAN Label TLV.........................11 7. Security Considerations.......................................12 8. Intellectual Property Considerations..........................13 9. References....................................................13 10. AuthorĘs Addresses...........................................14 11. Full Copyright statement.....................................15 1. Introduction In this document, a method is presented that automatically setups 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 setup a L2 tunnel, also called VLAN Label Switch Path (VLAN-LSP) in this document, the VLAN tags are distributed throughout Label Switched Routers (LSRs) by the Label Distribution Protocol (LDP). The main purpose of this document is to propose an LDP extension in order to enable LDP to establish and maintain L2 tunnels by distributing VLAN tags. 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. Section 6 provides the main contribution of this document - new label TLV in the LDP protocol. Expires - August 2003 [Page 2] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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 as well for Metropolitan Area Networks (MAN) and Wide Area Networks (WAN). Further, Layer 2 Virtual Private Networks (L2VPN) also uses the Ethernet technology. In this document, the use of Ethernet for MAN/WAN/L2VPN networks is described as wide area Ethernet. There are some applications of wide area Ethernet, e.g. an access network connecting user and Internet Service Provider (ISP), for which L2 tunnelling should be performed. For these applications, applying the standard Multi-Protocol Label Switching (MPLS) [3] leads to complex protocol stacks as in case of Ethernet over MPLS (EoMPLS) or PPP over Ethernet and L2 Tunnelling Protocol (PPPoE + L2TP). Trying to find simple solution for L2 tunnelling over Ethernet, we propose a method that uses the VLAN tag for label switching and, therefore, the use of Ethernet switches as LSRs. VLAN networks 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 proposed method of MPLS using VLAN tag switching, a group between two entities (e.g. user and ISP) is formed, and thus, performing a L2 tunnelling (virtual path) between them. Introducing this L2 tunnelling method for point-to- point connection over wide area Ethernet, 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 LDP is assumed for label distribution. Further a network management entity, called Network Manager, calculates the paths (VLAN-LSP) and it can control the network load. Expires - August 2003 [Page 3] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 +---------+ | 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. 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 Constraint-based Routing LDP, CR-LDP) and hop-by-hop setting (using standard LDP). The control (i.e. LDP) 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. Expires - August 2003 [Page 4] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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. Control packets (e.g. LDP 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. Expires - August 2003 [Page 5] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 The control interface connects control component and forwarding component. Transport of control (LDP) 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. CR-LDP) protocol and performing IP routing. After receiving and analysing a LDP packet, the control component generates a new LDP 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 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 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 Expires - August 2003 [Page 6] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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. 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 Expires - August 2003 [Page 7] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 encapsulation in any way. The description of the encapsulation in this section is fully conformant with the encapsulation proposed in [5]. 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 Expires - August 2003 [Page 8] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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. 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], CR-LDP [9], Border Gateway Protocol (BGP), and RSVP-TE. In this document, it is assumed that the label bindings are distributed only by LDP and/or CR-LDP. 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 set up employing the routing tables of the VLAN-LSR and knowing the IP address of the egress VLAN-LSR. On the other hand, if CR-LDP 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 edge VLAN- LSR uses CR-LDP signalling protocol to send Label Request Message to the VLAN-LSR having the next IP address in the Explicit Route TLV (ER-TLV). Once the control component of the edge VLAN-LSR receives the Label Mapping Message, it configures the forwarding component. To forward data packets along a VLAN-LSP, the forwarding component of ingress Expires - August 2003 [Page 9] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 VLAN-LSR SHOULD insert a VLAN tag in the Ethernet header. There are two possibilities to decide how to determine the VLAN tag: (1) Using CR-LDP The use of CR-LDP offers another two possibilities to determine the VLAN tag to be inserted in the incoming data packets: - The VID field of the VLAN tag is derived from LSPID TLV of the CR-LDP message using its "Local CR-LSP ID" field. More precisely, the "Local CR-LSP ID" field has length of 16 bit, while the VID field is only 12-bit long, and therefore, only first 12 bits of the "Local CR-LSP ID" field are used for defining the VID field. Having this in mind, the network management system (i.e. Network Manager) sets the "Local CR- LSP ID" field in such manner that the first 12 bits of this field are a unique identifier of the VLAN-LSP connection for the whole VLAN-LSR domain. - The control component may use the VID field from "VLAN label TLV" (defined in section 6) to determine the same named field in the VLAN tag. (2) Using LDP Since the "Local CR-LSP ID" field of the LSPID TLV is not available, the egress VLAN-LSR must determine the value of the VID value employing another methods. Thus, in order to avoid overlapping of the VID values because a number of VLAN-LSRs are present in the network, each egress VLAN-LSRs should require that value from the Network Manager. The Network Manager distributes the VID values using the "VLAN Label TLV" proposed in section 6. 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 When the control component of an internal VLAN-LSR receives (via LDP or CR-LDP) a Label Request Message for a certain VLAN-LSP from a peer connected to its VLAN-LSR, the control component takes the following actions: 1. it allocates a label (VID) There are two different cases for allocating of labels depending of the employed signalling protocol: Expires - August 2003 [Page 10] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 - Employing CR-LDP, the control component has two possibilities to decide how to configure the label of the forwarding component. First, it may use the "Local CR-LSP ID" field of LSPID TLV, included in the Label Request Message. In this case, the control component SHOULD use the first 12 bits of "Local CR-LSP ID" field to configure the label. Second, the control component may use the VID field from "VLAN label TLV" (defined in section 6) to allocate the label. - Employing LDP, the control component SHOULD use the VID field from in section 6 proposed "VLAN Label TLV", which is contained in the Label Mapping Message. 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 "Local CR-LSP ID" field) MAY be used for these two VLAN- LSPs. 2. it sends a Label Request Message to the downstream VLAN-LSR, which has the next address in the ER-TLV 3. it returns a Label Mapping Message back to the peer that originated the request. The VLAN-LSR SHOULD wait for the request to be satisfied from the downstream LSR because the "ordered control" is used (as defined in [3] and [6]), in particular "ingress-initiated ordered control". 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). Further, the procedures for CR-LDP defined in [9] are applied. 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 setup VLAN-LSP. This LDP extension includes the Expires - August 2003 [Page 11] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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 (CR- 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: 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. This value is allocated 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]. 7. 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 - August 2003 [Page 12] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 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]. 8. 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. 9. 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 - August 2003 [Page 13] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 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] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Worsten, T., Feldman, N., Fredette, A., Glrish, M., Gary, E., Heinanen, J., Kilty, T., and A. Mails, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002 10. 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, 1-1 Asahidai, Tatsunokuchi-Cho, Nomi-Gun, Ishikawa 923-1211 Japan Phone: +81 761 51 1699 ext. 1327 EMail: n-ogashi@jaist.ac.jp Expires - August 2003 [Page 14] INTERNET-DRAFT draft-kawakami-mpls-lsp-vlan-00.txt February 2003 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 11. 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 - August 2003 [Page 15]