One document matched: draft-jiang-l2vpn-vpls-mac-operation-00.txt
Network Working Group Y.L., Jiang
Internet Draft Y., Yang
Huawei
Intended status: Standards Track June 24, 2008
Expires: December 24, 2008
Optimized MAC Address Operations in VPLS with Redundancy
draft-jiang-l2vpn-vpls-mac-operation-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
This Internet-Draft will expire on December 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Virtual Private LAN Service (VPLS) Using Label Distribution
Protocol (LDP) Signaling is described in RFC 4762. That document
describes a mechanism called MAC Address Withdrawal to remove or
unlearn MAC addresses which have been dynamically learned in a VPLS
Jiang Expires Dec 2008 [Page 1]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
instance. Further work in progress defines an extension to MAC
Address Withdrawal procedure which can greatly restrict the scope of
MAC flushing. This document provides two mechanisms which completely
remove the need for MAC address flushing in VPLS instances. The
mechanisms are MAC address switching and MAC address notification.
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 [RFC2119].
Table of Contents
1. Introduction...................................................2
2. Scenarios......................................................3
3. Optimized MAC Address Operations...............................5
3.1. MAC Address Switching.....................................6
3.2. MAC Address Notification..................................6
4. LDP Extensions.................................................6
4.1. PW-ID TLV.................................................6
4.2. MAC Address Switching Message.............................9
4.3. MAC Address Notification Message.........................10
5. Signaling MAC Address Operations..............................11
6. Processing Rules..............................................11
6.1. Receipt of MAC Address Switching Message.................11
6.2. Receipt of MAC Address Notification Message..............12
7. Applicability.................................................12
8. Security Considerations.......................................12
9. IANA Considerations...........................................14
9.1. New LDP Message Types....................................14
9.2. New LDP TLV Type.........................................14
10. Acknowledgments..............................................14
11. References...................................................15
11.1. Normative References....................................15
11.2. Informative References..................................15
Author's Addresses...............................................15
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16
1. Introduction
A method of Virtual Private LAN Service (VPLS), also known as
Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is
Jiang Expires Dec 2008 [Page 2]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
created using a collection of one or more point-to-point pseudowires
(PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh
topology provides a LAN segment or broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses at the
PE devices.
A MAC Address Withdrawal mechanism is described in [RFC4762] to
remove or unlearn MAC addresses for faster convergence on topology
change [RFC4762]. But when a PE device in VPLS receives a MAC Flush
message it may also flush the MAC addresses which are not affected
by the topology change, thus leading to unnecessary flooding and MAC
relearning. [MAC-OPT] describes a solution to optimize the MAC flush
procedure so that only the MAC addresses affected by topology change
are flushed. This can greatly restrict the scope of MAC flushing.
Both of the methods provided by [RFC4762] and [MAC-OPT] must flush
the MAC addresses first, and then re-learn them by flooding all
frames with these MAC addresses as layer 2 destinations. This incurs
a waste of bandwidth and may even cause congestions in the MPLS core
network.
For PW switching scenarios introduced in [MAC-OPT] and [PW-RED],
when a working PE switches to a backup PE or a working PW switches
to a backup PW, its associated MAC address could be re-utilized
rather than flushed.
This document provides two mechanisms which completely remove the
need for MAC address flushing in VPLS instances. The mechanisms are
MAC address switching and MAC address notification.
2. Scenarios
Figure 1 demonstrates the VPLS reference model as explained in
[RFC4664]. PE devices that are VPLS-capable provide a logical
interconnect such that Customer Edge (CE) devices belonging to a
specific VPLS appear to be on a single bridged Ethernet. From Figure
1, we see that in a VPLS, a CE device attaches, possibly through an
access network, to a "bridge" module of a VPLS PE. Within the VPLS
PE, the bridge module attaches, through an "Emulated LAN Interface",
to an Emulated LAN. For each VPLS, there is an Emulated LAN
instance.
Figure 1 shows some internal structure to the Emulated LAN: it
consists of "VPLS Forwarder" modules connected by PWs, where the PWs
may travel through Packet Switched Network (PSN) tunnels over a
routed backbone. A "VPLS instance" consists of a set of VPLS
Forwarders (no more than one per PE) connected by the PWs in a full-
Jiang Expires Dec 2008 [Page 3]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
mesh configuration. Both the "bridge" and the "VPLS Forwarder"
should maintain forwarding tables that map MAC addresses to ACs or
PWs (they may be combined into a single table). The VPLS "bridge"
does MAC Source Address (SA) learning on frames received on ACs,
while the "VPLS Forwarder" does SA learning on PWs.
|-----Routed Backbone---|
| (P Routers) |PSN Tunnels,
Emulated LAN | |Pseudowires
.....................................................................
. | | .
. |---------------------|----| |--------|-----------------| .
. | --------------------|--- | | -------|---------------- | .
. | VPLS Forwarder | | VPLS Forwarder | .
. | ----------|------------- | | ----------|------------- | .
..|...............................................................|..
| | Emulated LAN | | | Emulated LAN |
| | Interface |VPLS-PEs | | Interface |
| | | <---> | | |
| ----------|------------ | | ----------|------------ |
| | Bridge | | | | Bridge | |
| -|--------|----------|- | | -|--------|----------|- |
|--|--------|----------|---| |--|--------|----------|---|
| | | | | |
| | Access | | | Access |
| | Networks | | | Networks |
| | | | | |
| | | | | |
CE devices CE devices
Figure 1 VPLS Architecture
Figure 2 describes a dual-homed H-VPLS scenario for a VPLS instance
where the proposed mechanisms can be applied.
In Figure 2, the Multi-Tenant Unit switch (MTU-s) is dual-homed to
PE-1 and PE-2. Only the primary spoke PW is active at MTU-s, thus
PE-1 acting as the primary device to reach the full mesh in the VPLS
instance. The MAC addresses located at customer sites (behind CE1
and CE2) are learned at PE-1 over the primary spoke PW. PE-2, PE-3
and PE-4 learn those MAC addresses on their respective mesh PWs
terminating at PE-1 (PW5, PW1, PW3). This is all as described in
[RFC4762].
When MTU-s switches to the backup spoke PW and activates it, PE-2
becomes the primary device to reach the full mesh core. Traffic
entering the H-VPLS from CE-1 and CE-2 is diverted by MTU-s to the
Jiang Expires Dec 2008 [Page 4]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
backup spoke PW, and then transferred across the full mesh core to
remote PE-3 or PE-4 by way of PW2 or PW4. For faster convergence
MTU-s may send a MAC flush message to PE-2 once the backup PW has
been made active, and PE-2 forwards the MAC flush message to PE-3
and PE-4. In this way, both [RFC4762] and [MAC-OPT] mechanisms will
flush MAC addresses associated with PW1 from PE-3, and those MAC
addresses associated with PW3 from PE-4. The addresses will be re-
learned by flooding frames with these MAC addresses as their
destinations. Additionally, PE-2 will have to re-learn the MAC
addresses behind customer sites CE-3 and CE-4 which PE-1 had
previously learnt from PW1 and PW3 respectively.
PE-1 PE-3
+--------+ +--------+
| | | |
| -- | PW1 | -- | CE-3
| / \ |----------------| / \ |--->
CE-1 /------| \ s/ | PW2 | \S / |
\ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+
\ (MTU-s)/ | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \/ |
| / \ | PW5| H-VPLS Full Mesh Core |
| \S / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ backup spoke PW | / \ PW3 |
/ \ +--------+ \------+--------+
CE-2 \ | | | |
\------| -- | PW4 | -- | CE-4
| / \ |----------------| / \ |--->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE-2 PE-4
Figure 2 Dual homed MTU-s in two tier hierarchy H-VPLS
3. Optimized MAC Address Operations
Two mechanisms for optimized MAC address operation are described in
this document, the first is MAC address switching, which can be used
by a PE node where both the working PW and the backup PW terminate
Jiang Expires Dec 2008 [Page 5]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
at the same PE; the other is MAC address notification, which can be
used when the working PW and the backup PW originate from two
different nodes (i.e. when a primary PE node switches the VPLS
service to a backup PE node). With these two mechanisms, flushing of
MAC address can be totally avoided under network scenarios such as
figure 2.
3.1. MAC Address Switching
The basic principle of MAC Address Switching is explained with
reference to Figure 2. When PW1 is switched to the backup PW2 (PW
switching may be realized in a mechanism described in [PW-RED] or in
some other way), PE-1 or PE-2 sends out a ''MAC Address Switching''
message to PE-3, and accordingly PE-3 changes its MAC table items
with PW1 as the outgoing PW, to show PW2 as the outgoing PW. In this
way, remote VPLS peer node PE-3 needs no MAC flushing and re-
learning, and faster convergence is realized. The message format and
the procedure of processing are defined in section 4.
3.2. MAC Address Notification
The basic principle of MAC Address Notification is explained with
reference to Figure 2. When PE-1 notifies PE-2 to transfer the VPLS
service, it notifies PE-2 of the MAC addresses it leant over the
working pseudowire PW1 and PW3. In this way PE-2 does not need to
re-learn them over PW2.
To facilitate MAC table maintenance on PE-2, the MAC Address
Notification messages should include the outgoing PWs to be
associated with the notified MAC addresses. Multiple PWs and their
associated MAC addresses may be carried in a single message or in
separate messages.
4. LDP Extensions
In order to realize MAC address switch and MAC address notification
mechanisms, some LDP extensions are defined in this document.
4.1. PW-ID TLV
The PW-ID TLV carries the unique identifier of a PW. The encoding of
PW-ID TLV follows standard LDP TLV encoding in [RFC5036], its
encoding is:
Jiang Expires Dec 2008 [Page 6]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW-ID TLV (0x0406) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW-ID Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 PW-ID TLV
U (Unknown) bit of PW-ID TLV MUST be set to 1. If the PW-ID TLV is
not understood then it is silently ignored.
F (Forward) MUST be set to 0. Since the LDP mechanism used here is
targeted, the TLV is not forwarded if it is not understood by the
receiving device.
The Type field MUST be set to 0x406 (subject to IANA approval). This
identifies the TLV type as PW-ID TLV.
Length field specifies the total length in octets of the Value in
the PW-ID TLV.
PW-ID Element encoding depends on the type of the PW-ID Element. A
PW-ID Element uniquely identifies a PW. A PW-ID Element value is
encoded as 1 octet field that specifies the element type, 1 octet
field that identifies the length in octets of the element value, and
a variable length field that is a type-dependent element value.
The PW-ID Element value encoding is:
PW-ID Element Type Length Value
Type name
FEC-128 specific 0x01 2 octets See below.
FEC-129 specific 0x02 Variable See below.
The type of PW-ID Element depends on the type of FEC Element used to
provision the respective PW. [RFC4447] defines two types of FEC
element that may be used for provisioning PWs - PWid FEC (type 128)
and the Generalized ID (GID) FEC (type 129). The PWid FEC element
includes a fixed-length 32 bit value called the PWid. The same PWid
value must be configured on the local and remote PE prior to PW
setup.
The GID FEC element includes TLV fields for attachment individual
identifiers (AII) that, in conjunction with an attachment group
identifier (AGI), serve as PW endpoint identifiers. The endpoint
Jiang Expires Dec 2008 [Page 7]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
identifier on the local PE (denoted as <AGI, source AII or SAII>) is
called the source attachment identifier (SAI) and the endpoint
identifier on the remote PE (denoted as <AGI, target AII or TAII>)
is called the target attachment identifier (TAI). The SAI and TAI
can be distinct values. This is useful for provisioning models where
the local PE (with a particular SAI) does not know and must somehow
learn (e.g. via MP-BGP auto-discovery) of remote TAI values prior to
launching PW setup messages towards the remote PE.
FEC-128 specific PW-ID Element
This sub-type is to be used to identify a PW endpoint only if PWid
FEC Element is used for signaling the PW. The encoding of this PW-ID
element is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | Length | PW type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 FEC-128 specific PW-ID Element
PW type
The PW Type value from PWid FEC element.
PW ID
The PW ID value from the PWid FEC element.
FEC-129 specific PW-ID element
This sub-type is to be used to identify a PW only if GID FEC
Element is used for signaling the PW. The encoding of this PW-ID
element is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | Length | PW type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAII TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 FEC-129 specific PW-ID Element
Jiang Expires Dec 2008 [Page 8]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
PW type
The PW Type value from GID FEC element.
AGI TLV
The AGI from the corresponding GID Element
SAII TLV
The SAII associated with the PW.
TAII TLV
The TAII associated with the PW.
4.2. MAC Address Switching Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address Switching (0x0302) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW-ID TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 MAC Address Switching Message
Message Type, this field identifies the type of LDP message "Address
Switching" and MUST be set to 0x0302. This value needs IANA approval.
Message Length, Specifies the cumulative length in octets of the
Message ID, MAC list TLV, and PW-ID TLV.
Message ID, a 32-bit value used to identify this message.
MAC List TLV, this field is defined in section 6.2.1 of [RFC4762].
Jiang Expires Dec 2008 [Page 9]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
PW-ID TLV, this field is defined in section 4.1 of this document.
4.3. MAC Address Notification Message
A new "MAC Address Notification" message is defined which includes a
MAC List TLV as defined in [RFC4762] and a PW-ID TLV as defined in
section 4.1 of this document. Multiple MAC List TLVs and PW-ID TLVs
MAY be included, and they MUST appear in pairs with the MAC List TLV
first. The detailed MAC Address Notification message is explained
here.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|Address Notification (0x0303)| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW-ID TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 MAC Address Notification Message
Message Type, this field identifies the type of LDP message "Address
Notification" and MUST be set to 0x0303. This value needs IANA
approval.
Message Length, Specifies the cumulative length in octets of the
Message ID, MAC list TLV, and PW-ID TLV.
Message ID, 32-bit value used to identify this message.
MAC list TLV, this field is defined in section 6.2.1 of [RFC4762].
PW-ID TLV, this field is defined in section 4.1 of this document.
Multiple pairs of MAC List and PW-ID TLVs MAY be present.
Jiang Expires Dec 2008 [Page 10]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
5. Signaling MAC Address Operations
MAC address notification and MAC address switching may be signaled
separately, or be combined with the PW redundancy signaling defined
in [PW-RED], thus when the PE node notifies its PW peer node about
its status, it can also carry the MAC address notification and MAC
Address Switching messages.
When the working PE node (PE-1 in Figure 2) decides to switch its
working PW to a standby PW (and the standby PW does not traverse the
working PE itself), the working PE node MAY send out a MAC Address
Notification message to its backup PE (i.e. PE-2 in Figure 2) with
MAC addresses listed in a MAC List TLV and the backup PW identified
in the PW-ID TLV, and MAY send out a MAC Address Switching message
for the respective working PW for each of the other VPLS peers with
MAC addresses in the MAC List TLV and its corresponding backup PW
identified in the PW-ID TLV.
When the backup PE node triggers PW switching, it MAY send out a MAC
Address Switching message for respective backup PW for each of the
other VPLS peers with its corresponding working PW in the PW-ID TLV.
Under some circumstances, PW endpoints may trigger PW switching in a
distributed way, and do the MAC address switching without any
signaling message. As no signaling is concerned, this kind of
scenario is out of the scope of this document.
6. Processing Rules
6.1. Receipt of MAC Address Switching Message
Upon receipt of the MAC address switching message, the peer PE node
SHOULD:
- Extract the PW-ID from the message;
- Verify that the PW identified by PW-ID and the PW from which the
message is received are protecting each other, otherwise MUST
ignore this message and MAY log an error locally;
- Identify the working PW and the backup PW from these two PWs;
- If MAC List TLV is null (absent or empty), then for each MAC
addresses in the forwarding table which is associated with the
working PW:
Jiang Expires Dec 2008 [Page 11]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
- associate the MAC address with backup PW in the forwarding
table
- Otherwise, for each MAC address in the MAC List TLV:
- associate the MAC address with the backup PW in the forwarding
table.
6.2. Receipt of MAC Address Notification Message
When a PE node receives a MAC Address Notification Message, after
verification it SHOULD add the MAC addresses carried in the message
to its FIB and associate them with the PW identified by the PW-ID
TLV carried in the message.
Upon receipt of a MAC Address Notification message, the peer node
SHOULD:
- Extract the PW-ID from the message;
- Verify that it is the backup PE for the PE from which this message
is received, and the PW identified by PW-ID is a backup PW
traverse itself, otherwise MUST ignore this message;
- For each MAC address in the MAC List TLV in the received message:
- associate the MAC address with the PW identified in the PW-ID
TLV in the message and store them in the forwarding table.
7. Applicability
This document defines the MAC Address Switching and MAC Address
Notification procedures and their application in optimized MAC
addresses operation in H-VPLS on topology change. These mechanisms
MAY also be used in the scenarios described in [PW-RED]. The use of
MAC Address Switching and MAC Address Notification procedures is
OPTIONAL.
8. Security Considerations
This section is to be enhanced in a future revision of this document.
- Control plane aspects
Jiang Expires Dec 2008 [Page 12]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
- LDP security (authentication) methods as described in
[RFC5036] are applicable here. Further this document
implements security considerations as in [RFC4447] and
[RFC4762].
- Data plane aspects
- This specification does not have any impact on the VPLS
forwarding plane.
Note that forged switchover messages, such as those defined in this
document, represent a significant risk to established PWs and the
traffic they carry. If an attack is successful, traffic may be
diverted to other destinations which may introduce a denial of
service risk (as the traffic may be black-holed or sent on non-
optimum paths), and may also represent a risk to the confidentiality
of the data being transferred. The use of standard LDP security
mechanisms, as described above, will mitigate this risk.
Additionally, cross-check mechanisms are included in the procedures
described in this document to ensure that the switchover of MAC
address information is expected.
Jiang Expires Dec 2008 [Page 13]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
9. IANA Considerations
9.1. New LDP Message Types
IANA maintains a registry of LDP code-points at "Label Distribution
Protocol (LDP) Name Spaces". There is a sub-registry for LDP message
types called "Message Type Name Space".
IANA is requested to allocate two new message types from the range
0x300-0x3ff. The following values are suggested:
Message Name Type
Address Switching 0x0302
Address Notification 0x0303
9.2. New LDP TLV Type
IANA maintains a registry of LDP code-points at "Label Distribution
Protocol (LDP) Name Spaces". There is a sub-registry for LDP TLV
type values called "Table, Length, and Value (TLV) Type Name Space".
IANA is requested to allocate a new value from the range 0x0000-
0x3DFF. The following value is suggested:
The TLV type of PW-ID is defined as 0x406 and subject to IANA
approval.
10. Acknowledgments
The authors would like to thank Adrian Farrel and Dan Li for their
valuable comments and suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Jiang Expires Dec 2008 [Page 14]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance
Using Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN
Services using LDP", RFC 4762, January 2007.
[RFC5036] Andersson, L., Minei, I., et al, "LDP Specification", RFC
5036, October 2007.
[PW-RED] Muley, P., et al, "Preferential Forwarding Status bit
definition", work in progress.
[MAC-OPT] Dutta, P., and Lasserre, M., "LDP Extensions for Optimized
MAC Address Withdrawal in H-VPLS", work in progress.
11.2. Informative References
[RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664, September
2006.
Author's Addresses
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: yljiang@huawei.com
Yang Yang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: healthinghearts@huawei.com
Jiang Expires Dec 2008 [Page 15]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jiang Expires Dec 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:19:55 |