Internet DRAFT - draft-kawakami-mpls-lsp-vlan
draft-kawakami-mpls-lsp-vlan
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]
