One document matched: draft-shah-pwe3-control-protocol-extension-01.txt
Differences from draft-shah-pwe3-control-protocol-extension-00.txt
Himanshu Shah
Ciena Networks
PWE3 Working Group
Internet Draft Hamid Ould-Brahim
Nortel Networks
June 2003
Expires: December 2003
Dynamic Parameters Signaling for MPLS-based Pseudowires
draft-shah-pwe3-control-protocol-extension-01.txt
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.
Abstract
This document describes a mechanism along with extensions to [PWE3-
CONTROL] draft that enable a PE to signal to the remote PE
additional dynamic information about the pseudowire. This
information may either be related to the operations of the
pseudowire such as operational state of the Attachment circuit, the
state of the pseudowire forwarders, the IP address and/or MAC
address of the attached CE, or may affect the setup of the
pseudowire, such as traffic engineering parameters, security related
information, etc.
Shah, et al. Expires December 2003 1
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
The proposal is backward compatible with existing [PWE3-CONTROL]
based pseudowire and provides a flexible mechanism for learning
remote end additional capabilities without requiring complex,
explicit pseudowire negotiation extensions and procedures.
1.0 Specification of Requirements
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.0 Introduction
The [PWE3-CONTROL] draft describes how two PEs signal VC-FEC to each
other in order to establish a pseudowire. The VC-FEC is exchanged
over the targeted LDP session and contains pseudowire signaling
information that is generally pre-provisioned and static (i.e., does
not change during the lifetime of the pseudowire).
However, there are situations and events that occur during the
lifetime of the pseudowire where a PE needs to inform the remote PE
about the up-to-date information related to normal functioning of
the pseudowire. Such information allows the receiving PE to take
appropriate actions when required. The additional information may
either be related to the operations of the pseudowire such as state
of the Attachment circuit, the state of the pseudowire forwarders,
the IP address and/or MAC address of the attached CE, etc, or may
affect setup of the pseudowire, such as traffic engineering
parameters, security related information, type of tunnel signaling
used, VPN related information, etc.
These drafts describes a mechanism whereby additional information
about the pseudowire can be dispatched with the VC-FEC without
requiring to a) tear down the pseudowire by withdrawing the PW-Label
and b) explicitly negotiate capabilities between PW PE peers. This
document does not define all the information elements that can be
passed optionally with the VC-FEC but rather a mechanism whereby
such information can be passed either during the setup or as an
update without requiring to tear down the existing pseudowire.
This document specifies various TLVs that can be included in the
initial Label Mapping Message and subsequently in LDP notification
message for conveying up-to-date information about the pseudowire.
Finally, this proposal is orthogonal to the type of VC-FEC used.
Both PWid FEC and Generalized ID FEC can make use of the new
additions. In the case of PWid FEC and for particular TLVs (such as
Status TLV) the additional signaled information can be related to
the GROUP_ID value when this field is used in signaling.
Shah, et al. Expires December 2003 2
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
3.0 Capability Learning and Dynamic Update Mechanisms
For the purpose of learning remote end capabilities and for the
purpose of signaling to the remote end the local capabilities, this
draft suggests that the various additional TLVs to be included
initially in the label mapping message and particularly in the
Optional Parameter field of Label Mapping Message. When subsequent
updates are required (after the PW is established), the sender PE
will use the LDP notification message to convey an update of the new
information..
Note that the mechanism described in this draft allows a given PE
that does not support the additional TLVs to be able to establish a
pseudowire using normal operations. Indeed, the PEs that are
upgraded with such new functionality, examine the optional
parameters and note each TLV to learn the capabilities of the
sending peer. The sender must include all the TLVs that it intends
to use later as an update in the Label Mapping message that is used
to setup the FIB. Typically, such Label Mapping message is either
the first Label Mapping message or the one right after the Label
Withdraw/Release message and is referred to in this document as a
"Learning Label Mapping" message.
The absence of a given TLV in the Learning Label Mapping message
indicates to the receiver that the sending PE is either not capable
of processing such TLV or does not wish to engage in dynamic update
exchange for that TLV. The absence of any additional TLV indicates
to the receiving PE that normal PW signaling procedures should be
used to establish the PW (i.e., no inclusion of the optional TLVs in
the reverse label mapping). Similarly, the receiving PE that has not
been upgraded with the new TLVs and receives a label mapping with
the new TLVs will just ignore these TLVs during label mapping
processing phase.
When the receiving PE learns the senderĘs new capabilities it
adjusts its behavior as follows: If the receiving PE didn't send its
label mapping message, it will then format a label mapping message
that contains all the new TLVs matching the received TLVs or
contains a subset of TLVs from the matching set that the receiving
PE intends to use during the life time of the pseudowire. If
however, the label mapping has been sent, the receiving PE will only
support the set of TLVs that both the sender and the receiver
support (i.e., the common denominator).
Once the capabilities of the remote peer has become known and the
pseudowire is operational, subsequent updates will be conveyed using
the LDP notification message which will contain only a subset or all
the TLVs taken from the set of TLVs that both the sender and the
receiving PE understand and agreed to exchange.
Shah, et al. Expires December 2003 3
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
Note that for Status TLV (see below), a PE that is capable of
supporting this TLV MUST include it in the LABEL MAPPING message.
This allows the remote PE to determine the actual Status of various
components of a given pseudowire type at the sender PE side. As an
example a PE receiving label mapping with negative status
information may decide upon local policy to not forward traffic to
the sender PE until new status information is received that clears
the previous problem.
The format of the Notification message is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User defined TLV(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.0 TLVs
4.1 Operational Status TLV
The Operational Status TLV is used to notify the remote PE peer
about the initial and the change in operational status of the
attached circuit or the tunnel carrying the PW. The exchange of this
information is an alternative to the current practice of withdrawing
the PW label for such circumstances.
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| Status TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
32-bit value specifies the operational status. A value of 0 means
that operational status is active. A value of 1 means that AC or
PW is inactive
Each PE is responsible for coordinating the status notification for
his local AC and PW. For example, if PEx detects AC down and
Shah, et al. Expires December 2003 4
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
notifies PEy and if PEy uses this information to inactivate his
corresponding AC, it must not notify back to PEx about his AC down.
In effect, each PE must view notifying the status to remote as his
responsibility only when his capability to propagate traffic from AC
to PW is compromised. The state of the traffic propagation from PW
to AC is largely dependent on remote PEĘs status notifications.
This rule must be observed to avoid any deadlock arising from
interdependent status exchanges.
4.2 IP Address TLV
The IP Address TLV is used to notify the remote PE about the IP
address of the locally attached CE. This information is useful for
point-to-point Layer 2 interworking circuit [SHAH-ARP].
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| IP Address TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address
32-bit field contains IP address of the attached CE. When value is
zero, the IP address of the attached CE is not known or has become
unknown.
The [SHAH-ARP] draft describes the need to exchange and how to
process such information.
4.3 IP+MAC Address TLV
The IP+MAC Address TLV is used to notify the remote PE about the IP
and MAC address of the locally attached CE. This information is
useful for multipoint-to-multipoint pseudowire for IP as described
in [SHAH-IPLS] document.
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| IP Address TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Multicast Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address
Shah, et al. Expires December 2003 5
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
32-bit field contains IP address of the attached CE. When value is
zero, the IP address of the attached CE is not known or has become
unknown.
MAC Address
48-bit field contains MAC address of the attached CE. When the
value is zero, the MAC address of the attached CE is not known or
has become unknown.
Multicast Flag
Value one indicates that pseudowire carry only multicast traffic.
The [SHAH-IPLS] draft describes the need to exchange and how to
process such information.
4.4 Pseudowire QOS TLV
The pseudowire QOS TLV is used to notify the remote PE about tunnel
signaling mechanisms and traffic engineering parameters to be used
to setup the ingress pseudowire from the remote to the advertising
PE. As stated earlier, this information can also be passed as an
update. It is possible that receiver may either adjust QOS
parameters of the existing tunnel or may respond to the update by
first withdrawing the advertised PW label and re-advertise new PW
label with same VC-FEC.
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 QOS TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Information Rate (PIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Type
16-bit value identifies the signaling mechanisms to be used to
setup the tunnel over which the PW is mapped. A value of 0
indicates that tunnel type is not specified. A value of 1
indicates use of LDP and a value of 2 indicate use of RSVP-TE.
When tunnel type is LDP, QOS parameters are ignored. When there is
a mismatch between the sender and the receiverĘs Tunnel Type,
receiver and sender both defaults to LDP tunnel type.
Traffic Engineering Parameters
Shah, et al. Expires December 2003 6
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
Each TE parameter is encoded as a 32-bit IEEE single precision
floating-point number. The CIR and PIR are in units of bytes per
second while CBS and PBS are in units of bytes.
The PW QOS TLV conveys traffic engineering parameters that
advertising PE would like remote PE to consider when
selecting/creating appropriate transport tunnel to carry the
pseudowire from remote PE to the advertising PE. The traffic
engineering parameters can also be used to select appropriate
traffic shaper and policer for the attached circuit at the remote
PE.
5.0 General Procedures
The TLVs described in this document are mandatory for some
pseudowire types and layer-2 vpn services (e.g. ARP mediation,
IPLS).. In general, when Notification message is used as an update
mechanism and ęwithdrawĘ of optional parameters is realized by
issuing the Notification message with same TLVs as an update with
null values in some cases. This alleviates the need to cycle through
Label Withdraw followed by Label Mapping message to convey new
parameters as is the current situation with [PWE3-CONTROL].
Future revision of this document will contain additional information
of other TLVs that are useful as adjunct information for the VC-FEC.
6.0 Security Considerations
The security aspects of this solution will be discussed at a later
time.
7.0 References
[PWE3-CONTROL] Martini et. Al., "Transport of Layer 2 Frames Over
MPLS", draft-ietf-pwe3-control-protocol-02.txt, February 2003 (work in
progress)
[LDP] L. Andersson, P. Doolan, N. Feldman, A.
Fredette, B. Thomas, "LDP Specification", RFC3036, January 2001.
[SHAH-ARP] Shah et. Al., "ARP Mediation for IP interworking of Layer
2 VPN", Draft-shah-ppvpn-arp-mediation-02.txt, June 2003 (work in
progress)
[SHAH-IPLS] Shah et. Al., "IP-Only LAN Service", Draft-shah-ppvpn-
ipls-02.txt. June 2003. (work in progress).
Acknowledgement
The authors would like to thank David Allan for his constructive
input.
Shah, et al. Expires December 2003 7
Internet Draft draft-shah-pwe3-control-protocol-extension-01.txt
Author's Address
Himanshu Shah
Ciena Networks
35 Nagog Park
Acton, MA 01720
Email: hshah@ciena.com
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7, Canada
Email: hbrahim@nortelnetworks.com
Full copyright statement
Copyright (C) The Internet Society (1999). 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 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.
Shah, et al. Expires December 2003 8 | PAFTECH AB 2003-2026 | 2026-04-19 07:43:46 |