Himanshu Shah
K. Arvind
Internet Draft Tenor Networks
draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt
Sunil Khandekar
Vach Kompella
TiMetra Networks
Ashwin Moranganti
Dave Ward
Appian Communications
Giles Heron
PacketExchange, Ltd.
Expires: August 2002 February 2002
Signaling between PE and L2PE/MTU for Decoupled VPLS and
Hierarchical VPLS
draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
2. Abstract
The [DTLS] draft identifies the need for an information exchange
mechanism between a PE device and its adjunct L2PE devices in the
decoupled transparent LAN architecture. For example, the PE needs to
provide information to an L2PE about the existence of remote
site(s), and the MPLS label(s) that the L2PE needs to use to reach
those site(s). The [HVPLS] draft requires signaling between the PE-
rs and the MTU-s device to setup the spoke VC connection for the
VPLS service.
Shah Informational - Expires May 2002 1
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
This draft proposes an LDP based approach for such exchange
mechanisms. The mechanisms proposed here allow:
- The L2PE, in case of [DTLS], to provide an acceptable set of
incoming labels to PE.
- The MTU-s, in case of [HVPLS], to negotiate the spoke VC labels
with the PE.
Optionally, this draft also allows the PE to provide TLS specific
configuration to an L2PE or MTU-s device.
3. ID Summary
SUMMARY
This ID describes information exchange between PE and adjunct L2PE
devices, which together offer transparent LAN services for Layer 2
VPN solution.
RELATED DOCUMENTS
draft-kompella-ppvpn-dtls-00.txt,
draft-khandekar-ppvpn-hvpls-00.txt
draft-knight-l2vpn-lpe-ad-00.txt
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
Belongs in PPVPN
WHY IS IT TARGETED AT THIS WG
This document describes a mechanism to assist in Provider-
Provisioned Layer 2 VPNs.
JUSTIFICATION
We believe that when VPLS is offered using the layer 2 VPN solution,
it is desirable to accommodate network topologies where PE and an
adjunct [DTLS]L2PE or [HVPLS]MTU-s device together offer
connectivity to the customer devices. In such scenario, PE and
L2PE/MTU-s need to exchange label information needed for packet
forwarding and optionally customer specific information. This
document provides this exchange mechanism and interpretation
guidelines for L2PE/MTU-s.
4. Introduction
The [DTLS] draft describes methodologies by which a PE device can
relegate traditional bridging functions to adjunct L2PE devices
while restricting itself to L2VPN signaling activities. In such
configurations, a PE device would be responsible for providing the
remote site membership information to its attached L2PEs.
Shah, et al. Expires August 2002 Page 2
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
The [HVPLS] draft describes a model where the base [VPLS] solution
is enhanced with a hierarchical connectivity approach to eliminate
the full mesh VC requirements. Since the PE is also performing
bridging functions in this model, the need for an LSP per remote
site between PE and adjunct MTU-s device is replaced by a single LSP
per TLS.
In either case, the PE and L2PE/MTU-s devices need to exchange label
information for each VPLS.
This document identifies the information elements employed for this
purpose and describes how LDP is used as the distribution mechanism.
It also describes how an L2PE/MTU-s device interprets and processes
such information. The goal is to provide an interoperable way to
facilitate vendor partnerships when offering the L2VPN DTLS and
HVPLS solutions.
The [DTLS] solution refers to the bridging device typically placed
in the Multi-Tenant Unit(MTU) as the L2PE while the [HVPLS] solution
refers to the same device as the MTU-s denoting a switching or a
bridging capable MTU device. To avoid confusion, the rest of this
document will refer to this device simply as the MTU device.
5. Information Elements
5.1. DTLS
The [DTLS] document identifies various pieces of information pushed
by a PE device to its adjunct MTU devices:
(1) Virtual Private LAN Service (VPLS)-related MTU configuration
information: Distribution of the information is optional and is
described later in the document in Section 5.2.
(2) Label information: The set of labels that the PE device and MTU
device will use to identify various remote sites.
Label information is specified as a set of label ranges, where each
label range consists of a base label value, an offset that
identifies the site corresponding to the base label, and the number
of sites in the range. Each label in the range corresponds to a
connection to a remote site.
[DTLS] deviates from traditional MPLS in that the label distributed
by the PE to the MTU is considered a bi-directional label. Suppose a
PE device P distributes label X (associated with remote site R) to
an adjunct MTU device L. In traditional MPLS label distribution,
this is a signal from P to L that L should use label X in all
packets that it routes to R via P. [DTLS] specifies that P will also
use label X in all packets from R that are directed towards L.
However, incoming labels are resources that are usually allocated by
the receiving node (L) rather than the transmitting node (P).
Depending on the available label space in the receiving node L,
Shah, et al. Expires August 2002 Page 3
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
label allocation by the transmitting node P may create issues. This
draft proposes that an MTU device optionally be able to notify or
negotiate an acceptable label range with its PE device.
[TBD - The need for the bi-direcionality requirement for labels used
between the PE and MTU that [DTLS] specifies is not clear. If this
requirement can be relaxed, one could fall back to the traditional
LDP label exchange mechanism, where each side proposes labels that
it is happy with].
The proposed approach provides a twofold advantage. Firstly, it
allows an MTU to signal its limitations (if any) on handling the
bit-size for the incoming label width. Secondly, if an MTU device is
dual-homed to two PE devices on a shared LAN, the MTU device can
provide disjoint label ranges to each PE device. This can be used to
avoid overlap and hence eliminate the confusion at the MTU device
about the origin of data packets received on the LAN.
This document recommends exclusion of the circuit status bit vector
information from the distributed label information. This is replaced
by the explicit withdrawal of the corresponding label when the
connection to a remote site is interrupted. This works well with the
[HVPLS] architecture, as the notion of a circuit status bit vector
is absent. Also, in [HVPLS], the label per remote site paradigm does
not exist eliminating the need for notification when remote site
reachability is interrupted.
The [DTLS] draft also requires that a PE device advertise a
contiguous block of labels of size n to an MTU device, when it
advertises a block of VPN labels of size n to remote PEs. This draft
relaxes the requirement that the PE advertise the n labels to the
MTU device in a single block. It allows the advertisement of
multiple label blocks that need not be contiguous to each other, as
long as the total number of labels advertised to the MTU device is
equal to n.
5.2. HVPLS
HVPLS works with either an MTU that is capable of signaling and can
participate in DTLS, or with a legacy MTU that is capable of
imposing customer-delimiting VLAN tags. Since a PE-rs in the HVPLS
terminology can do replication, it does not require the MTU to send
multiple packets with different labels in a label range to effect a
replication. The PE therefore has to send only a single label to a
DTLS-enabled MTU.
6. MTU related configuration on PE
The [DTLS] document suggests MTU specific configuration on PE to be,
<<MTU ID (router ID)>>
<connecting interface>
<<TLS ID> <MTU site ID>>
Shah, et al. Expires August 2002 Page 4
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
<<MTU port ID, VLAN Tag> <MTU port ID, VLAN Tag> . . .>
<<TLS ID> <MTU site ID>>
<<MTU port ID, VLAN Tag> <MTU port ID, VLAN Tag> . . .>
. . .
>
Here, PE is configured with MTU's router ID and interface that
connects to the MTU. Additionally, for each VPLS/TLS and MTU site ID
pair, a set of MTU's customer facing port ID and VLAN tag pairs are
configured on the PE.
The configuration of MTU port ID and VLAN tag specific information
on the PE is optional. The distribution of this optional
configuration information is discussed in section 6.2.
7. Exchange Mechanism using LDP
There are several protocols that can be used to exchange TLS
specific information between PE and MTU. Among them LDP seems most
suitable for exchanging information that essentially consists of
labels.
7.1. MTU FEC Element
An MTU FEC Element is encapsulated in a FEC TLV. The following MTU
FEC Element is sent in a Label Mapping message using downstream-
unsolicited distribution.
The MTU FEC Element has a one-to-one correspondence with the Label
TLV that follows the MTU FEC Element. The MTU must process the L2PE
FEC and Label TLV within the scope of the associated LDP session,
which in turn may run within the scope of the interface that
directly connects L2PE and PE. The association of the L2PE FEC and
Label TLV with a specific interface is important for two reasons.
Firstly, it allows labels to be interface-specific and secondly it
provides an L2PE with information about the interface on which it
should forward packets with the allocated label to the PE. .
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Type |H| Reserved | Site Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS ID (most significant 4-bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS ID (least significant 4-bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shah, et al. Expires August 2002 Page 5
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
7.1.1. MTU Type
The MTU type field identifies the FEC Element as an MTU FEC Element.
The value is TBD.
7.1.2. H bit
The H bit, when set, is used to indicate to the MTU that the PE is
an HVPLS PE.
7.1.3. Reserved
This field is reserved for now and must be set to zero and ignored
on receipt.
7.1.4. Site Identifier
Site identifier is a 2-byte value assigned by a PE. The site
identifier has VPLS scope and is used for administrative purposes.
In [HVPLS], the Site Identifier value is not used. It must be set to
zero when sending and ignored on receipt.
7.1.5. VPLS Identifier
The VPLS identifier is an 8-byte value assigned by the PE. The value
identifies a VPLS for the MTU. An MTU must treat each VPLS as a
logical bridge instance with its own configuration, flooding scope,
forwarding information base and spanning tree protocol. The PE
treats each VPLS as a VPN instance and engages in locating and
establishing connections to remote PE that participates in the same
VPN (or VPLS).
7.2. Label Signaling
A conventional LDP Label TLV is used to signal labels. However,
since a label range needs to be signaled, two optional parameters
are defined for the Label TLV.
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| Label TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RSID | Length = 2 | Remote Site ID Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LS | Length = 2 | Label Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shah, et al. Expires August 2002 Page 6
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
Instead of a label, the Label Base is specified in the TLV.
Following the Label Base, there are two optional parameters that
MUST be present when the PE is a DTLS PE. Note that since HVPLS
needs only one label, these two sub-TLVs are not necessary. The
codepoints for the Remote Site ID Base TLV and Label Size TLV are
TBD.
7.2.1. Remote Site ID Base TLV
This field along with the Label Size field enables the association
of remote sites with MTU labels. The site identified by the Remote
Site ID Base field is associated with the label value specified in
the Label TLV associated with this FEC. The site identified by the
site ID obtained by incrementing the Remote Site ID Base value by n
is associated with the label value obtained by incrementing the
value specified in the Label TLV by n, where n ranges from 1 to
Label Size-1. The knowledge of remote site IDs at an MTU is for
administrative purposes only. The MTU does not use the remote site
ID value in making data packet forwarding decisions. The MTU however
uses the label value for data packet forwarding.
In [HVPLS], the Remote Site ID Base TLV is ignored, and MAY be
omitted.
7.2.2. Label Size TLV
The Label Size TLV indicates the width of a contiguous set of labels
starting from label base. The label base is indicated in the
associated label TLV.
Each label in the label set represents a possible connection to a
remote site that is part of the VPLS L2VPN. In essence, an MTU
should treat each label as a "logical interface" that is mapped to
the physical interface directly connecting the MTU to the PE. The
[DTLS] specification describes the special rules of operations for
such logical interfaces, such as modified learning, modified
forwarding, etc.
It is important that an MTU treat each label as an individual entity
even when it is advertised as a set. The advantage of this approach
is that individual labels can be withdrawn without having to
withdraw the entire list.
When one or more labels are withdrawn, an MTU must unlearn all the
MAC addresses associated with each label. Also, an MTU must maintain
each label within the context of its LDP session for reasons
mentioned earlier.
The Label Size field is not necessary for [HVPLS] and MAY be set to
zero on send and ignored on receipt, or set to 2 (indicating that
Shah, et al. Expires August 2002 Page 7
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
there are 2 MTUs in this MTU's context, itself, and the rest of the
VPLS behind the PE). No other values are defined for HVPLS.
7.3. Configuration TLV
The configuration TLV is part of the set of optional parameters that
is present in a Label Mapping message. The Configuration TLV
associated with the MTU FEC provides configuration information to
MTU that specifies customer-facing ports that are members of the
TLS identified by the MTU FEC. The configuration TLV is optional
for [DTLS] and [HVPLS] architecture.
The organization of a configuration TLV is a hierarchy of sub-TLVs.
The physical port attributes are set in the Port Config TLV.
Following that, a logical port TLV defines further delimiters for
logical ports. Logical port attributes such as bandwidth capacity
of the logical port are also included. All logical port attributes
are optional.
In the cases when there is new configuration information but no new
label information, the label size field in MTU FEC is set to zero,
the label base value is set to one of the labels already advertised
and only the configuration TLV information is relevant. This is also
applicable to label withdraw message in which a label size field
value of 0 in the MTU FEC should be treated as an indication to
ignore the label values and apply withdraw to configuration TLV.
This mechanism allows notifications of add and delete of customer
facing ports independent of label notifications for the remote
sites.
Refer to the following diagram for the definition of the
configuration TLV.
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| Config TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Port Config TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Reserved | MTU unit# | MTU slot# | MTU card# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU port# | MTU Channel# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Optional Logical Port Attribute TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Logical Port Config TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T | Customer Delimiting Field |
Shah, et al. Expires August 2002 Page 8
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Logical Port BW TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
| Other Optional Logical Port Attribute TLVs |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Reserved | MTU unit# | MTU slot# | MTU card# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU port# | MTU Channel# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Optional Logical Port Attribute TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Logical Port Config TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T | Customer Delimiting Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Logical Port BW TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
| Other Optional Logical Port Attribute TLVs |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3.1. Config TLV Type
The field identifies the configuration TLV. The value is TBD.
7.3.2. Length
The Length field represents the total number of bytes in the value
field that follows the length field.
7.3.3. MTU port ID
The MTU port ID is represented in hierarchical fashion. There are
five sub-fields, with unit number at the top of the hierarchy and
channel number at the bottom. The value zero in any of the sub-fields
indicates absence of that category. The MTU port number is the only
exception to this rule and must contain a non-zero value.
[Note: We are not aware of any standard hierarchical way of
identifying ports on a detached network device. Comments welcome]
Shah, et al. Expires August 2002 Page 9
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
The MTU must identify the port ID before processing the associated
VLAN tag and bandwidth information. The same port Id may repeat in
different information elements to carry different VLAN tag and
bandwidth information. However, when both port Id and VLAN tag pair
are same in two information elements, the bandwidth value from later
information element is used for update.
7.3.3.1. Reserved
Not used at present. [TBD - This could be turned into a user
definable field to allow vendors to add more information related to a
given MTU port ID, if necessary].
7.3.3.2. MTU unit number
The MTU unit number field allows cascading of multiple ethermux boxes
to be represented as single manageable device. For such
configuration, unit number uniquely identifies a particular ethermux
switch. If MTU is a single physical unit, this field should be set to
zero.
7.3.3.3. MTU Slot number
If an MTU device is slot-based, the non-zero value is used to
identify a slot. The value zero indicates slot number field is not
used.
7.3.3.4. MTU card number
If an MTU device is slot-based and each slot can hold more than one
card, a non-zero value must be set to identify the appropriate card.
The value zero indicates the slot does not contain multiple cards.
7.3.3.5. MTU port number
Every Ethernet device has Ethernet port. This value must be non-zero.
The port value is relative to card, slot and unit values as described
earlier.
7.3.3.6. MTU channel number
The channel number represents a channel on a physical port. If an
Ethernet port is not channelized, this field must be set to zero.
7.3.4. Logical Port Config TLV
The Logical Port Config provides the logical port delimiter to be
used for the customer access port.
Shah, et al. Expires August 2002 Page 10
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
7.3.4.1. T bits
The T bits identify the type of customer delimiter. Currently, only
VLAN tags are defined. The value of T is TBD for VLAN tagging. When
the T bits are set for VLAN tagging, the associated VLAN tag is used
to tag any untagged Ethernet frame received on that port as required
by the port-based 802.1Q VLAN operations. Similarly, the outgoing
frame must be untagged if the VLAN tag were to be of the same value
as the associated VLAN tag field.
7.3.4.2. Customer Delimiting Field
Only VLAN tags are currently defined as Customer Delimiting Fields.
A VLAN ID is a 12-bit field. Any value other than 0x000 and 0x0ff
represents a valid 802.1Q VLAN id. The VLAN id field is used to
either identify or tag an incoming frame based on the setting of the
T bits. The MTU must register the presence of the VLAN tag within the
scope of the VPLS and accord 802.1Q based services, such as flooding,
spanning tree processing, etc. for the VLANs identified for the VPLS.
The value 0x000 is used to indicate absence of a VLAN tag field.
7.3.5. Logical Port Bandwidth TLV
The Logical Port Bandwidth TLV provides traffic parameters for the
customer port.
7.3.5.1. Bandwidth
Bandwidth is a 2-byte field. When non-zero, it represents a value in
megabits per second (TBD: use IntServ floating point bandwidth format
instead). If MTU is capable of discriminating traffic and provide
resources to achieve bandwidth based traffic shaping, it should use
the associated VLAN tag field and the bandwidth value to achieve this
goal.
8. MTU to PE
MTU may optionally notify its TLS membership to its directly
attached PE. It may also optionally include the range of MTU labels
that MTU is capable of processing for a given TLS for the given LDP
session.
For TLS membership notification, MTU uses label TLV and MTU TLV in
the same format as described above. The MTU FEC contains a valid
L2PE type, site ID, and TLS ID. All the rest of the fields are set
to zero.
When MTU also wants to relay the MTU label range, it provides the
starting label value in label TLV and the size value in the label
size field of the MTU FEC. For example, if MTU wants PE to use
Shah, et al. Expires August 2002 Page 11
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
labels between 8K and 12K, it would set label value in label TLV to
be 8K and the size value to be (4k-1) in the label size field of the
MTU FEC.
MTU may also optionally notify PE about its role for PE. The [DTLS]
and [HVPLS] describes operation rules for primary and secondary role
for the PE.
9. Two PEs connected to same MTU on shared LAN
As stated earlier, MTU could be configured with disjoint label
ranges for each PE. MTU would then advertise this information to PE
at the beginning of the session. PE must advertise the label subsets
from the range received from MTU for remote connections
notifications. MTU can now identify distinctly a remote connection
through a PE for a given TLS based on the incoming label in the
received data packet.
10. One PE connected to two MTU supporting same TLS on shared LAN
This is handled by PE and MTUs configured with distinct site
identifier and MTU configured with disjoint label ranges.
11. Acknowledgments
The authors would like to thank Tim Mancour, Bill Townsend, Arnold
Sodder, Xavier Briard and David Bahi for their valued comments.
12. Security considerations
The security aspects of this solution will be discussed at a later
time.
13. References
[L2VPN] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella-
mpls-l2vpn-02.txt, November 2000.
[DTLS] Kompella et al., "Decoupled Transparent LAN Services", draft-
kompella-ppvpn-dtls-01.txt
[HVPLS] Khandekar et al., "Hierarchical Virtual Private LAN
Service", draft-khandekar-ppvpn-hvpls-mpls-00.txt.
14. Authors' Addresses
Himanshu Shah
Tenor Networks
100 Nagog Park
Acton, MA 01720
Email: hshah@tenornetworks.com
Shah, et al. Expires August 2002 Page 12
Draft draft-shah-ppvpn-vpls-pe-mtu-signaling.txt February 2002
K. Arvind
Tenor Networks
100 Nagog Park
Acton, MA 01720
Email: arvind@tenornetworks.com
Sunil Khandekar and Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: sunil@timetra.com
Email: vkompella@timetra.com
Ashwin Moranganti and Dave Ward
Appian Communications
35 Nagog Park,
Acton, MA 01720
Email: amoranganti@appiancom.com
Email: dward@appiancom.com
Giles Heron
PacketExchange Ltd.
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
e-mail: giles@packetexchange.net
Shah, et al. Expires August 2002 Page 13