One document matched: draft-shah-pwe3-control-protocol-extension-00.txt
Himanshu Shah
Tenor Networks
PWE3 Working Group
Internet Draft
draft-shah-pwe3-control-protocol-extension-00.txt
February 2003
Expires: August 2003
Extensions to Transport of Layer 2 frames over MPLS
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 extensions to [PWE3-CONTROL] draft to enable
exchange of additional information about the Pseudowire without
having to withdraw the VC-FEC first.
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 Pseudowire
related information to each other in order to establish a
Pseudowire. This information, called VC-FEC, is exchanged over the
Shah, et al. Expires August 2003 1
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
targeted LDP session and contains Pseudowire specific information
that is static. If any of this information is to change, label
mapping for the VC-FEC must be withdrawn and re-advertised with the
changed VC-FEC.
This draft describes a mechanism whereby additional information
about the Pseudowire that can be dispatched with the VC-FEC without
having to first withdraw the PW-Label for the advertised VC-FEC.
This additional information may either be related to the operations
of the Pseudowire such as state of the Attachment circuit, 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. 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 having to first tearing
down the existing Pseudowire.
This document recommends that such information be passed as LDP TLVs
in the optional parameter field of the Label Mapping message for the
VC-FEC.
3.0 LDP
The [PWE3-Control] uses downstream unsolicited Label Mapping message
to advertise the VC-FEC for a given Pseudowire. The [LDP] document
section 3.5.7 defines the encoding of Label Mapping message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
FEC TLV
Specifies the FEC component of the FEC-Label mapping being
advertised. The [PWE3-Control] document specifies the FEC
Element for the Pseudowire for the FEC TLV. This is commonly
referred to as VC-FEC.
Shah, et al. Expires August 2003 2
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
Label TLV
Specifies the Label component of the FEC-Label mapping.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV.
This document specifies various TLVs that can be included in
Optional Parameter field of Label Mapping Message as a mean to
provide additional attributes for the Pseudowire.
When these TLVs are passed as an update to an existing VC-FEC, the
Label Mapping message is sent with the same VC-FEC and the label
that was advertised earlier.
4.0 TLVs
4.1 Operational Status TLV
The Operational Status TLV is used to notify the remote PE peer
about 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type
16-bit value is used to identify the interface type. A value of 1
means operational status is for the attachment circuit. A value of
2 means that operational status is for the unidirectional portion
of the PW that spans from advertising PE to the receiving PE.
Status
16-bit value specifies the operational status. A value of 0 means
that AC or PW is down or inactive while a value of 1 means that AC
or PW is up or active.
The absence of status TLV in optional parameter of Label Mapping
message for the VC-FEC must not be interpreted as status down. In
fact, PEs should assume operational status of the remote attachment
circuit and incoming PW as operational unless notified otherwise.
The operational status down must then be followed by operational
status up in order for remote PE to resume traffic.
Shah, et al. Expires August 2003 3
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
The sender has the responsibility to coordinate the status
notifications. The receiver may or may not react to these
notifications.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
MAC Address
Shah, et al. Expires August 2003 4
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
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.
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 then 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 Inforation 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.
Traffic Engineering Parameters
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 establishing
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.
Shah, et al. Expires August 2003 5
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
5.0 General Procedures
The TLVs described in this document are mandatory for some
pseudowire types (e.g. ARP mediation, IPLS) while optional but
useful for others. In general, where necessary, †withdrawË of
optional parameters is realized by issuing the Label Mapping message
with same TLVs as an update with value zero. This alleviates the
need to cycle through Label Withdraw followed by Label Mapping
message to convey new parameters.
The receiving PE must always inspect Optional Parameter field of the
Label Mapping message to detect the presence of these TLVs. When a
Label Mapping message is received with the same PW label for the
same VC-FEC from same remote Peer, TLVs must be examined to detect
the change in attributes before discarding the message as a
†duplicateË.
The future revision of this document will contain more definitions
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-01.txt, August 2002 (work in
progress)
[LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A.
Fredette, B. Thomas. January 2001. RFC3036
[shah-arp] Shah et. Al., ŸARP Mediation for IP interworking of Layer
2 VPN÷, Draft-shah-ppvpn-arp-mediation-01.txt, June 2002 (work in
progress)
[shah-ipls] Shah et. Al., ŸIP over LAN Service÷, Draft-shah-ppvpn-
ipls-00.txt. October 2002. (work in progress).
Author's Address
Himanshu Shah
Tenor Networks
100 Nagog Park
Acton, MA 01720
Email: hshah@tenornetworks.com
Full copyright statement
Shah, et al. Expires August 2003 6
Internet Draft draft-shah-pwe3-control-protocol-extension-00.txt
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 August 2003 7
| PAFTECH AB 2003-2026 | 2026-04-19 08:01:30 |