One document matched: draft-shah-pwe3-pw-qos-signaling-02.txt
Differences from draft-shah-pwe3-pw-qos-signaling-01.txt
Himanshu Shah
Ciena Corp
Ping Pan
Hammerhead Systems
PWE3 Working Group
Internet Draft Hamid Ould-Brahim
Nortel Networks
February 2005 Chris Metz
Expires: August 2005 Cisco Systems
Qos Signaling for PW
draft-shah-pwe3-pw-qos-signaling-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 discusses how a tail-end PE can signal the Quality of
Service parameters of the local Attachment Circuit to the head-end
PE for appropriate Pseudowire generation from head to tail end PE.
Shah, et al. Expires August 2005 1
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
The Pseudowires traditionally provide connectivity between two
Attachment Circuits that are on the edges of a service provider’s
network. A service provider assigns specific QOS parameters (i.e.
via manual configuration or dynamic signaling) to these Attachment
Circuits based on the service sold to the customer. In order to
interconnect and maintain the same level of service parameters
across the service provider network, it is prudent that the Provider
Edge devices that are endpoints of the Pseudowires, select or create
a suitable transport path that meets the Pseudowire’s quality of
service requirements. It is also possible that a PE may use
appropriate policing for traffic entering Pseudowire that match
remote Attachment Circuit’s capabilities as well as perform an
admission control check to ensure that the PE can indeed support the
desired QOS.
In order to accomplish an integrated service delivery it becomes
necessary that each PE understand the QOS requirements of the remote
Attachment Circuit.
This draft proposes an extension to the PWE3 control signaling to
enable a PE to exchange QOS parameters of the local Attachment
Circuit at the time of the PW establishment.
With advent of recent interest in multi-segmented Pseudowire
signaling the Pseudowire specific QOS requirements through multiple
PSN domains has become an important step in procuring the right
resources through intermediate PEs that perform Pseudowire
stitching.
In this revision we have added some more parameters that address
some of the requirements placed by Multi-hop Pseudowire Signaling.
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 PW-FEC to each
other in order to establish a pseudowire. The PW-FEC is exchanged
over the targeted LDP session and contains Pseudowire signaling
information that includes interface parameters of the local
Attachment Circuit.
Recently, [MH-PWE3] has introduced the concept of pseudowire
switching to interconnect data flows between multiple networks (or
domains). In pseudowire switching, one or multiple transit pseudo-
wires nodes are involved in pseudo-wire setup and subsequent data
forwarding.
Shah, et al. Expires August 2005 2
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
For both single-hop as well as multi-hop pseudowires, exchanging
Attachment Circuit QoS information can be very important for
carriers.
For example, as shown in Figure-1, both CE1 and CE3 communicate with
CE2. A single-hop pseudowire, PW12, is established between PE1 and
PE2 to transfer traffic between CE1 and CE2. Similarly, PW32 is to
carry traffic between CE3 and CE2.
PW12 (PW12+PW32)
| |
| |
+-----+ \|/ +-----+ |
+-----+ | |---------------| | \|/ +-----+
| CE1 |=======| PE1 |...............| PE2 |==========| CE2 |
+-----+ | |---------------| | +-----+
+-----+ +-----+
PW32 | . |
| | . |
| | . |
+-----+ \|/ | . |
+-----+ | |----------------+ . |
| CE3 |=======| PE3 |................... |
+-----+ | |--------------------+
+-----+
Figure-1: Over-subscription problem in PWE3
For carriers to offer or guarantee any service beyond best-effort
between two CE's, the access links between CE and PE have to have
enough network resources to accommodate the sum of all pseudo-wire
traffic going to a specific CE. In the example, the link between
PE2 and CE2 must be able to support the traffic from both PW12 and
PW32.
However, there is no mechanism available today to convey pseudo-wire
resource usage information between PE's. In today’s deployment, the
carriers have been using manual configuration to overcome the over-
subscription problem. Lack of automation will likely introduce setup
errors and diagnostics problems as the number of pseudo-wires begin
to increase.
Shah, et al. Expires August 2005 3
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
Native |<---------Pseudo Wire----------->| Native
Layer2 | | Layer2
Service | |<-PSN1->| |<-PSN2->| | Service
(AC) V V V V V V (AC)
| +----+ +-----+ +----+ |
+----+ | | PE1|========| PE2 |========| PE3| | +----+
| |----------|........PW1........|..PW3........|----------| |
| CE1| | | | | | | | | |CE2 |
| |----------|........PW2........|..PW4........|----------| |
+----+ | | |========| |========| | | +----+
^ +----+ +-----+ +----+ | ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| |
|<------------------ Emulated Service ----------------->|
Figure 2: PW switching Reference Model
If manual configuring QoS information is tedious in single-hop
pseudo-wire, multi-hop pseudo-wire can make the job worse. Figure-2
is its reference model.
A multi-hop pseudo-wire consists of multiple segments. When a
particular pseudo-wire requires QoS guarantees, the actual QoS
enforcement needs to be carried out at each segment. Subsequently,
each PW switching point needs to be aware of the QoS parameters of
the AC.
This draft describes a mechanism whereby additional information,
such as QOS parameters of the local Attachment Circuit can be
dispatched with the VC-FEC in a backward compatible fashion.
This document specifies QOS TLV 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.
This proposal is orthogonal to the type of PW-FEC used. Both PWid
FEC (value 128) and Generalized ID FEC (value 129) can make use of
the new additions. In the case of PWid FEC the signaled QOS
information can be related to the GROUP_ID value when this field is
used in signaling. The term VC-FEC and PW-FEC is used
interchangeably in this document and refers to both the FEC Ids.
It is expected that capability of exchanging QOS information
dynamically would facilitate various applications to optimize the
use of core resources effectively. For example, a PE may use this
signaling for backpressure when ‘forward congestion’ is detected on
its local AC.
Shah, et al. Expires August 2005 4
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
3.0 Capability Learning for QOS exchange
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 QOS TLV 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 QOS TLV 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 QOS TLV to learn the capability of the sending
peer. The sender must include the QOS TLV 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 QOS 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.
The capability learning aspect of the PW QOS is only applicable for
the use of QOS TLV for dynamic update notifications. It does not
change the need to send the initial QOS TLV, irrespective of whether
remote PE is capable of processing the optional TLV or not.
It is also possible that the receiving PE is capable of processing
QOS TLV and uses unacceptable QOS requirement as a criterion to
release the VC-FEC. In such event, a status TLV is defined to be
included in the optional parameter field of the label release
message that informs the remote PE about the reasons for the
rejection.
4.0 Pseudowire QOS TLV
The pseudowire QOS TLV is used to notify the remote PE about Quality
of Service requirements of the local Attachment Circuit.
As stated earlier, this information can also be passed as an update.
It is possible that receiver may either adjust QOS parameters of the
Shah, et al. Expires August 2005 5
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
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.
It is possible to send more than one QOS TLVs. The Flag field in the
QOS TLV provides the context for each 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW QOS TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Information Rate (PIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|D| Number of Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (1-n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Flags
This field contains set of flag. There are two flags bits are
defined currently. They are,
D – Direction flag. The value zero in Direction Flag means Forward
direction. The forward direction typically represents the
direction from the advertiser to the receiver. The value 1 in
Direction flag means Reverse direction. The reverse direction
typically represents the return path to the advertiser.
R – Request/Available flag. The value zero in Request/Available
flag means Requested QOS by the advertiser. The value one means
what is available. In multi-segment PW signaling intermediate PEs
can adjust the available QOS when propagating the signal towards
the destination PE.
The rest of the bits in the Flag field are reserved. They should
be set to zero on send and ignored on receive.
Number of Sub-TLVs
Shah, et al. Expires August 2005 6
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
This field identifies the number of Sub-TLVs that follow. In
absence of any Sub-TLVs, this field should be set to zero. This
field is mandatory.
Sub-TLVs (1-n)
The n number of Type-Length-Value fields where ‘n’ is equal to
‘Number of Sub-TLVs’ field. The presence of field facilitates
future/proprietary extensions
5.0 New LDP Status Codes
We define two types of status code.
One is to signal a fatal error. For example, a PE or a switching
node may reject pseudo-wire setup requests if QoS criteria cannot be
met. To reject a request, he node will include the error conditions
in the Status TLV that is a part of Label Release messages.
Another type of status provides advisory information. Contrary to
the previous case, a node may decide to setup the pseudo-wires even
though it cannot or don’t care to comply with the required QoS
parameters. Here, the node will send a Notification message to the
sender that includes the appropriated information in a Status TLV.
In case of multi-hop pseudo-wires, it is also possible that a
pseudo-wire may traverse several PSN’s. When setting up pseudo-wires
over GRE tunnels, it is very likely that the underlying traffic
conditioning mechanism is IP DiffServ, which does not guarantee per-
flow bandwidth or burst. In this case, the pseudo-wire switching
nodes need to notify such mis-matching behavior toward the sender.
The format of the PW Status TLV is:
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 Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the status code is a 4 octet bit field is specified in the PW
IANA Allocations document [13].
According to Section 4.4 in [LDP], we can define new status codes
in the range of 0x20000000-0x3effffff. Here are the new status
codes:
- 0x20000003 "TC is OK"
- 0x20000004 "Cannot accept the TC parameters"
- 0x20000005 "Preempted due to TC processing"
Shah, et al. Expires August 2005 7
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
- 0x20000006 “Accept PW but not comply with TC”
- 0x20000007 “Setup PW over DiffServ PSN”
6.0 General Procedures
The PW QOS TLV is included in the Optional Parameter Field of the
Label Mapping Message and the LDP Notification Message. In case of
Label Mapping Message, Optional Parameter Field follows the Label
TLV object. In LDP Notification Message, Optional Parameter Field
must include PW-FEC TLV before QOS-TLV. As described above, exchange
of QOS TLV in Notification Message is determined by the capability
learning during the initial Label Mapping exchange.
The PW QOS TLV conveys Quality of Service 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 Quality of
Service parameters can also be used by the receiving PE to select
appropriate policer for his Attached Circuit or perform an admission
control check.
The QOS TLV is optional. The received PE uses this information as a
suggestion.
Note that use of PW QOS exchange helps utilize core resources
effectively in the following manner.
. Head end PE selects a transport tunnel that best suits remote
Attachment Circuit’s QOS requirement
. More PWs can be multiplexed over a transport tunnel
. Transport tunnel can be right-sized with various upsize and
downsize thresholds
. Eliminates the wastage of packet forwarding resources in the
core when received traffic exceeds the Attachment Circuit QOS
criteria at the tail end.
7.0 The role of PW QOS in multi-hop PW signaling
In a multi-segmented Pseudo-wire, each intermediate PE stitches two
pseudo-wire segments in order to create a pseudo-wire from source PE
to destination PE through multiple PSN domains. In this topology it
becomes necessary that each PE hop ‘knows’ what the QOS requirements
are for this multi-segmented pseudo-wire so that it can procure the
correct network resources in each direction.
It is expected that source PE may include a set of QOS TLVs, one for
each direction, requested and available QOS parameters in the
initial Label Mapping message. Each intermediate PE then uses this
QOS information to acquire network resources and if unsuccessful, to
reject the multi-hop Pseudo-wire generation through that PE hop. The
Available QOS TLV could be adjusted at each PE hop in order for the
destination PE to determine the suitability of the end-to-end
Pseudo-wire path.
Shah, et al. Expires August 2005 8
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
The details for signaling PW QOS and it’s processing at each hops as
well as at the source and destination PE would be discussed in the
future revision of this document.
8.0 Security Considerations
The security aspects of this solution will be discussed at a later
time.
9.0 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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
10.0 Normative Reference
[PWE3-CONTROL] Martini, et al., “Transport of Layer 2 Frames Over
MPLS”, draft-ietf-pwe3-control-protocol-14.txt
[MH-PWE3] L. Martini, et al., "Requirements for inter domain Pseudo-
Wires", draft-martini-pwe3-MH-PW-requirements-00.txt
[LDP] L. Andersson, et al, "LDP Specification", draft-ietf-mpls-
rfc3036bis-00.txt
Shah, et al. Expires August 2005 9
Internet Draft draft-shah-pwe3-PW-Qos-Signaling-02.txt
Acknowledgement
Author's Address
Himanshu Shah
Ciena Corp
35 Nagog Park
Acton, MA 01720
Email: hshah@ciena.com
Ping Pan
Hammerhead Systems
640 Clyde Court
Mountain View, CA 94043
Email: ppan@hammerheadsystems.com
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7, Canada
Email: hbrahim@nortelnetworks.com
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
Email: chmetz@cisco.com
Full copyright statement
Copyright (C) The Internet Society (2005). 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.
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 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.
Shah, et al. Expires August 2005 10
| PAFTECH AB 2003-2026 | 2026-04-19 09:39:13 |