Network Working Group Fatai Zhang
Internet Draft Suresh B R
Category: Standards Track SenthilKumarS
Jun Sun
Huawei
Expires: July 3, 2010 January 4, 2010
Extensions to the Path Computation Element Communication Protocol for
Traffic Engineering Label Switched Paths in SDH Networks
draft-zhang-pce-pcep-extensions-for-sdh-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 3, 2010.
Abstract
[GMPLS-REQ] describes functional requirements for Generalized Multi-
Protocol Label Switching (GMPLS) application of Path Computation
Element (PCE). This document explains the application-specific
extensions for the Path Computation Element Communication Protocol
(PCEP) to support SDH. PCEP is the communication protocol defined by
IETF in RFC5440.
zhang Expires July 2010 [Page 1]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
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 [RFC2119].
Table of Contents
1. Introduction.................................................2
1.1. Requirements Language...................................3
2. Terminology..................................................3
3. Requirements.................................................3
4. Protocol Procedure and Extensions............................4
4.1. RP Object Extension.....................................4
4.1.1. Requested GMPLS Label Information..................5
4.2. No-PATH Object Extension................................6
4.2.1. Extensions to NO-PATH-VECTOR TLV...................6
4.3. END-POINTS Object Extension.............................7
4.3.1. Destination Prefix Information TLV.................7
4.4. New Object - QoS........................................8
4.4.1. SDH-ASON QoS Parameters TLV........................9
4.4.2. LSP Protection Information TLV....................13
4.4.3. QoS Object in PCReq and PCRep.....................15
4.5. Additional Error Type and Error Values Defined.........16
5. Manageability Considerations................................17
6. IANA Considerations.........................................17
6.1. New PCEP Object........................................17
6.2. New PCEP TLVs..........................................18
6.3. PCEP RP Object Flag Field..............................18
6.4. PCEP NO-PATH-VECTOR TLV Flag Field.....................18
6.5. New PCEP Error Codes...................................19
7. Security Considerations.....................................19
8. References..................................................20
8.1. Normative References...................................20
8.2. Informative References.................................20
9. Authors' Addresses..........................................21
1. Introduction
RFC4655 defines the PCE based architecture and explains how a PCE may
compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at
the request of Path Computation Clients (PCCs).
Zhang Expires July 2010 [Page 2]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
RFC5440 specifies the PCEP for communication between a PCC and a PCE,
or between two PCEs, in compliance with RFC4657. However, that
specification does not provide a mechanism to request path
computation for establishing TE LSPs in SDH network. [GMPLS-REQ]
addresses the functional requirements for GMPLS in PCE application.
This document describes the protocol extensions to PCEP to support
path computation for SDH networks.
1.1. Requirements Language
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 RFC2119.
2. Terminology
The following terminology is used in this document.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element.
PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
PCEP: Path Computation Element Communication Protocol. PCEP is a
request/response protocol used for the communication between a
PCC and a PCE, or between two PCEs.
PCEP Peer: An element involved in a PCEP session (For example, a PCC
or a PCE).
PCEP Session: The PCEP session is a logical connection established
automatically between the PCEP peers.
This document also uses the terminology defined in RFC4655, and
RFC5440.
3. Requirements
This section summarizes the PCEP extensions for GMPLS requirements
specific to SDH networks. This document introduces no new messages
for PCEP. However, extensions have been introduced to the existing
PCEP objects, sub-objects and TLVs. Also, few new objects and TLVs
Zhang Expires July 2010 [Page 3]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
have been introduced to support SDH. The details on the PCEP objects
and TLVs are mentioned below:
Enhanced Objects
o PCEP RP Object
o PCEP End Point (IPv4/Node ID) Object
Newly Introduced Object
o PCEP QoS Object
Newly Introduced TLVs
o Requested GMPLS Label
o Destination Prefix Information
o SONET/SDH QoS Parameters
o LSP Protection Information
4. Protocol Procedure and Extensions
4.1. RP Object Extension
The PCE architecture can be extended to support various network types
such as SDH, WDM, OTN, PTN and so on. The application-specific PCEP
requirements and protocol enhancements varies from network to network.
PCE MAY select the appropriate policy profile depending on the
current path request which is applicable to a particular network type.
The PCC can specify its network type in the RP object of the PCEP
protocol. The RP (Request Parameters) object MUST be carried within
each PCReq and PCRep messages and MAY be carried within PCNtf and
PCErr messages. The RP object can handle the requests and responses
of various network types for the computation of TE LSPs.
The RP object can also specify the next hop information. The simple
routing implementation can perform route look-up using the
destination IP address ignoring the additional information contained
in the request. More sophisticated routing implementations can use
additional information contained in the request to influence route
selection. This additional information includes resource class, input
network interface, traffic and service parameters.
The modified RP object carrying the additional information is as
follows:
Zhang Expires July 2010 [Page 4]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Class | OT |Res|P|I| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT | Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT - Network Type (3-bits). This field denotes the network type.
Bit NT Type
000 DC: Data Communication Networks (default)
001 SDH: Synchronous Digital Hierarchy Network
010 WDM: Wavelength Division Multiplexing Network
011 OTN: Optical Transport Network
100 PTN: Packet Transport Network
111 Multi-layered path request
The RP object carrying bits ranging from 101 to 110 in the NT flag
must be ignored. In future these bits can be used to represent new
network types.
4.1.1. Requested GMPLS Label Information
The Requested GMPLS Label Information TLV is a new OPTIONAL TLV and
MUST only appear inside RP object. The receiver SHOULD ignore the TLV
if it appears in any other object other than RP object. This TLV will
appear only when the resources required are requested using
generalized label. If multiple instance of this TLV is present, the
receiver SHOULD accept the first instance and SHOULD ignore the rest.
The format of Requested GMPLS Label Information TLV is as follows:
Zhang Expires July 2010 [Page 5]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding | Switching | Carried |
| Type | Type | Payload ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16-bits) - Specifies the type of the TLV (Value = 13).
Length (16-bits) - Specifies the length of the value field (Value =
4).
Encoding Type (8-bits) - Specifies the encoding type of the LSP being
requested.
The details of Encoding type is discussed in RFC 3471.
Switching Type (8-bits) - Specifies the switching type requested by
the LSP.
The details of Switching type is discussed in RFC 3471.
Carried Payload ID (16-bits) - Specifies the ID of the payload
carried by the LSP.
4.2. No-PATH Object Extension
The NO-PATH object is used in PCRep messages in response to an
unsuccessful path computation request (the PCE could not find a path
by satisfying the set of constraints). In this scenario, PCE MUST
include a NO-PATH object in the PCRep message.
The N0-PATH object carries the NO-PATH-VECTOR TLV that specifies more
information on the reasons that led to a negative reply. In case of
SDH networks there could be some more additional constraints that led
to the failure like protection mismatch, lack of resources, and so on.
Few new flags have been introduced in 32-bit flag field of the NO-
PATH-VECTOR TLV and no modifications have been made in the NO-PATH
object.
4.2.1. Extensions to NO-PATH-VECTOR TLV
The modified NO-PATH-VECTOR TLV carrying the additional information
is as follows:
Zhang Expires July 2010 [Page 6]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |N|P|U|U|N|
| Field |R|M|S|D|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
New fields PM and NR are defined in the 28th and 27th bit of the
Flags field respectively.
PM - Protection Mismatch (1-bit). Specifies the mismatch of the
protection type in the request.
NR - No Resource (1-bit). Specifies that the resources are not
currently sufficient to provide the path.
4.3. END-POINTS Object Extension
The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for
which a path computation is requested. New OPTIONAL TLVs are defined
that are to be carried in the END-POINTS object for the path that
depends on the previous hop address, destination prefix, and
additional interface information.
4.3.1. Destination Prefix Information TLV
The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST
only appear inside END-POINTS (IPv4/Node ID) object. The receiver
SHOULD ignore the Destination Prefix Information TLV if it appears in
any other object other than END-POINTS object. This TLV contains the
prefix length for the destination IPv4 address and will appear when
prefix length is in the range between 0 and 32 (inclusive).
The format of the Destination Prefix Information TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination | Flags |E| Reserved |
| Prefix Length | Field |M| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang Expires July 2010 [Page 7]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
Destination Prefix Length (8-bits) - Specifies the prefix length of
the destination IPv4 address.
Flags Field (7-bits) - Reserved for future to define new flags. It
MUST be filled with zeros and SHOULD be ignored by the receiver.
EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match
is required for the destination IPv4 address.
Bit EM Type
0 Exact prefix match is not required
1 Exact prefix match is required
Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be
ignored by the receiver.
4.4. New Object - QoS
When a PCC requests a PCE for a route, and if PCE provides the
response to the request, it MAY be useful for the PCC and the PCE to
include the traffic parameters. These traffic parameters specify a
base set of capabilities for SDH networks such as Service Level
Agreement (SLA), protection scheme, segment recovery, concatenation,
transparency, and so on. The QoS object handles the quality of
service parameters for TE-LSPs in SDH networks.
The QoS object can be included in the PCReq and PCRep messages by the
PCC and PCE respectively. It represents the parameters that become
necessary to manage bandwidth in the networks. When a PCE cannot find
a path by satisfying a set of constraints requested by the PCC, the
PCE may also include the original constraint so as to indicate the
reason for an unsuccessful computation in the NO-PATH object. Based
on the available service parameters proposed by a PCE, the PCC MAY
decide to resend the path requests. These parameters ensure that the
applications are guaranteed the network resources they need, despite
varying traffic load.
The format of the QoS object is as follows:
Zhang Expires July 2010 [Page 8]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Class | OT |Res|P|I| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// SDH-ASON QoS //
| Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// LSP Protection Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class (8-bits) - Specifies the class of the object (Value =
25).
OT - Object Type (4-bits) - Specifies the type of the object (Value =
1).
Object Length (16-bits) - Specifies the length of the object (Value =
16).
Res - Reserved (2-bits). It MUST be set to zero on transmission and
MUST be ignored on receipt.
P - Processing Rule (1-bit). The P flag allows a PCC to specify in a
PCReq message sent to a PCE whether the object must be taken into
account by the PCE during path computation or is just optional. When
the P flag is set, the object MUST be taken into account by the PCE.
Conversely, when the P flag is cleared, the object is optional and
the PCE can ignore it.
I - Ignore (1-bit). The I flag is used by a PCE in a PCRep message to
indicate to a PCC whether an optional object is processed or not. The
PCE MAY include the ignored optional object in its reply and set the
I flag to indicate that the optional object was ignored during path
computation. When the I flag is cleared, the PCE indicates that the
optional object was processed during the path computation. The
setting of the I flag for optional objects are purely indicative and
optional. The I flag has no meaning in a PCRep message when the P
flag has been set in the corresponding PCReq message.
4.4.1. SDH-ASON QoS Parameters TLV
The SDH-ASON QoS Parameters TLV is a new OPTIONAL TLV. It MUST only
appear inside QoS object. The receiver SHOULD ignore the SDH-ASON QoS
Parameters TLV if it appears in any other object other than QoS
object. Only one instance of this TLV MUST be present inside QoS
Zhang Expires July 2010 [Page 9]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
object. This TLV contains the parameters such as signal-type,
Requested Contiguous Concatenation (RCC), multiplier, Number of
Virtual Components (NVC), Number of Contiguous Concatenation (NCC),
transparency, and profile.
The format of the SDH-ASON QoS Parameters TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 34 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RCC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | NCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparency (T) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16-bits) - Specifies the type of the TLV (Value = 34).
Length (16-bits) - Specifies the length of the value field (Value =
16).
ST - Signal Type (8-bits). Specifies the type of elementary signal
that comprises the requested LSP. Several transforms can be applied
successively on the elementary signal to build the final signal being
actually requested for the LSP.
Each transform application is optional and must be ignored if zero,
except the Multiplier (MT) that cannot be zero and is ignored if
equal to one.
Transforms must be applied strictly in the following order:
o First, contiguous concatenation (by using the RCC and NCC fields)
can be optionally applied on the elementary signal, resulting in
a contiguously concatenated signal.
o Second, virtual concatenation (by using the NVC field) can be
optionally applied on the elementary signal resulting in
virtually concatenated signal.
Zhang Expires July 2010 [Page 10]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
o Third, some transparency (by using the Transparency field) can be
optionally specified when requesting a frame as signal rather
than an SPE or VC based signal.
o Fourth, a multiplication (by using the MT field) can be optionally
applied either directly on the elementary signal, or on the
contiguously concatenated signal obtained from the first phase,
or on the virtually concatenated signal obtained from the second
phase, or on these signals combined with some transparency.
The permitted values for SDH-ASON are as follows:
Bit Type (Elementary Signal)
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
4 VT6 SPE / VC-2
5 STS-1 SPE / VC-3
6 STS-3c SPE / VC-4
7 STS-1 / STM-0 (only when requesting transparency)
8 STS-3 / STM-1 (only when requesting transparency)
9 STS-12 / STM-4 (only when requesting transparency)
10 STS-48 / STM-16(only when requesting transparency)
11 STS-192 / STM-64(only when requesting transparency)
12 STS-768 / STM-256(only when requesting transparency)
RCC - Requested Contiguous Concatenation (8 bits). This field is used
to request the optional SDH contiguous concatenation of the
elementary signal. This field is a vector of flags. Each flag
indicates the support of a particular type of contiguous
concatenation. Several flags can be set at the same time to indicate
a choice.
All the bits should be cleared if contiguous concatenation is not
requested. A non-zero field indicates that some contiguous
concatenation is requested.
NCC - Number of Contiguous Components (16 bits). Specifies the number
of identical SDH VCs (for example, elementary signal) that are
requested to be concatenated, as specified in the RCC field.
When requesting a transparent STS-N/STM-N signal limited to a single
contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be
STS-N/STM-N, RCC with flag 1 and NCC set to 1. The NCC value must be
consistent with the type of contiguous concatenation being requested
in the RCC field. In particular, this field is irrelevant if no
contiguous concatenation is requested (RCC = 0), in that case it must
be set to zero when sent, and should be ignored when received. A RCC
Zhang Expires July 2010 [Page 11]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
value different from 0 must imply a number of contiguous components
greater than 1.
NVC - Number of Virtual Components (16 bits). Specifies the number of
signals that are requested to be virtually concatenated. These
signals are all of the same type by definition. They are elementary
signal SPEs/VCs for which signal types are VT1.5_SPE/VC-11, VT2_SPE/
VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS-3c_SPE/VC-4.
This field is set to 0 (default value) to indicate that no virtual
concatenation is requested.
MT - Multiplier (16 bits). Specifies the number of identical signals
that are requested for the LSP to form the final signal. These
signals can be either identical elementary signals, or identical
contiguous concatenated signals, or identical virtual concatenated
signals. Note that all these signals belong to the same LSP.
This field is set to one (default value) to indicate that exactly one
instance of a signal is being requested.
T - Transparency (32 bits). Specifies a vector of flags that
indicates the type of transparency being requested. Several flags can
be combined to provide different types of transparency. Not all
combinations are necessarily valid. The default value for this field
is zero, which means no transparency is requested.
Note as well that transparency is only applicable when using the
following signal types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS-
48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one
transparency type must be specified when requesting such a signal
type.
The different transparency flags are the following:
o Flag 1 (bit 1): Section/Regenerator Section layer
o Flag 2 (bit 2): Line/Multiplex Section layer
Where bit 1 is the low order bit. Other flags are reserved, they
should be set to zero when sent, and should be ignored when received.
A flag is set to one to indicate that the corresponding transparency
is requested.
P - Profile (32 bits). This field is intended to indicate particular
capabilities that must be supported for the LSP, for example
monitoring capabilities.
Zhang Expires July 2010 [Page 12]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
No standard profile is currently defined and this field SHOULD be set
to zero when transmitted and SHOULD be ignored when received. In the
future TLV based extensions may be created.
4.4.2. LSP Protection Information TLV
This is a new OPTIONAL TLV and MUST only appear inside QoS object.
This TLV contains the constraints related to protection which
includes SLA, protection scheme, segment recovery, and so on.
The format of the LSP Protection Information TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 40 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|U|S|D|D|L|R| Reserved |R|I|O|N|W|E|P|
|T|P|H|T|P|E|R| | |P| | |P|P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection | Segment | Associated |
| Scheme | Recovery | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16-bits) - Specifies the type of the TLV (Value = 40).
Length (16-bits) - Specifies the length of the value field (Value =
8).
Protection Flags
o ET - Extra Traffic Flag (1-bit). Specifies the extra traffic flag.
It basically stands for the iron traffic that is preemptible. The
LSP should use links that are protecting other (primary) traffic.
Such LSPs may be preempted when the links carrying the (primary)
traffic fails.
o UP - Unprotected Flag (1-bit). Specifies the unprotected traffic,
copper. The LSP will not use any link layer protection.
o SH - Shared Flag (1-bit). Specifies the shared traffic, silver. A
shared link layer protection scheme, such as 1:N protection,
should be used to support the LSP.
o DT - Dedicated 1:1 Flag (1-bit). Specifies the dedicated 1:1
service, gold. A dedicated link layer protection scheme (1:1
protection) should be used to support the LSP.
Zhang Expires July 2010 [Page 13]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
o DP - Dedicated 1+1 Flag (1-bit). Specifies the dedicated 1+1
service, diamond. A dedicated link layer protection scheme (1+1
protection) should be used to support the LSP.
o LE - Link Enhanced Flag (1 bit). Specifies the enhanced features
for a link, where a protection scheme that is more reliable than
dedicated 1+1 should be used, such as 4 fiber BLSR/MS-SPRING.
o RR - Reroute Flag (1-bit). Specifies the reroute flag. If set the
service is rerouted.
Reserved (18 bits) - Reserved for future. This field MUST be set to
zero on transmission and MUST be ignored on receipt.
Additional Protection Flags
o R - Required Flag (1-bit).
o IP - In Place Flag (1-bit).
o O - Operational Flag (1 bit).
o N - Change Notification Flag (1-bit). Specifies the change in the
protection flags.
o WP - Working or Protection Flag (1-bit). Specifies the working
LSP (bit value = 0) or protection LSP (bit value = 1).
o EP - Extended Protection Flag (1-bit).
o PS - Primary or Secondary Flag (1-bit). Specifies whether to
signal and reserve the resources of the primary LSP (bit value =
0) or secondary LSP (bit value = 1).
Protection Scheme (8-bits) - Specifies the protection scheme of the
LSP. It can carry the following values based on the requested
protection type:
Value Protection Scheme Type
0x00 No end-to-end protection (iron service)
0x01 Reroute protection (silver service)
0x02 1:1 protection without extra traffic (gold service)
0x03 1+1 protection and is uni-directional (diamond service)
Zhang Expires July 2010 [Page 14]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
0x04 1+1 protection, and is bi-directional (diamond service)
0x05 Reserved for new protection schemes
0xFE Reserved for new protection schemes
0xFF Reserved for future
Segment Recovery (8-bits) - Specifies the recovered segment of the
LSP.
Associated LSP ID (16-bits) - Specifies the LSP ID of the associated
service. During re-routing or optimization, the traffic prevents the
route of the associated one.
4.4.3. QoS Object in PCReq and PCRep
As mentioned earlier the QoS object MAY be included in the PCReq
message specifying the traffic parameters. This object is OPTIONAL,
and if present only one instance of SDH-ASON QoS parameters TLV or
LSP protection TLV must be included. If multiple instances of TLV or
some other TLV is present, then the complete message has to be
discarded without performing any further processing.
The format of the PCReq message including the QoS object is as
follows:
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>[<svec-list>]
<request-list> ::= <request>[<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<QoS>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
Zhang Expires July 2010 [Page 15]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
The format of the PCRep message is as follows:
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list> ::= <response>[<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path>[<path-list>]
<path> ::= <ERO><attribute-list>
where:
<attribute-list> ::= [<LSPA>]
[<BANDWIDTH>]
[<QoS>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC>[<metric-list>]
4.5. Additional Error Type and Error Values Defined
A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error
type. An additional error type and few error values are defined to
represent some of the errors related to the newly identified objects
related to SDH networks.
For each PCEP error, an Error-Type and an Error-value are defined.
Error-Type 1 to 10 are already defined in RFC5440. Additional Error-
values are defined for Error-Type 10 and a new Error-Type 14 is
introduced.
Error-Type Error-value
10 Reception of an invalid object
Zhang Expires July 2010 [Page 16]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
Error-value=2: Requested GMPLS Label information TLV
missing in RP object.
Error-value=3: LSP Protection Information TLV missing
in QoS object.
Error-value=4: TLV missing in QoS object.
Error-value=5: Multiple instance of TLV present in
QoS object.
Error-value=6: Unsupported TLV present in QoS object.
Error-value=7: SONET/SDH QoS parameters TLV missing
in QoS object.
14 Path computation failure
Error-value=1: Unacceptable response message.
Error-value=2: QoS object missing in request message.
5. Manageability Considerations
Liveness Detection and Monitoring
This document makes no change to the basic operation of PCEP and so
there are no changes to the requirements for liveness detection and
monitoring set out in RFC4657 and RFC5440.
6. IANA Considerations
IANA assigns values to the PCEP protocol objects and TLVs. IANA is
requested to make some allocations for the newly defined objects and
TLVs introduced in this document. Also, IANA is requested to manage
the space of flags that are newly added in the TLVs.
6.1. New PCEP Object
IANA is requested to make some allocations for the QoS object:
Object-Class Value Name Reference
25 QoS Object-Type-1 This document (section 4.4)
Zhang Expires July 2010 [Page 17]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
6.2. New PCEP TLVs
IANA is requested to create a registry for the following TLVs:
Value Meaning Reference
13 Requested GMPLS Label This document (section 4.1.1)
20 Destination Prefix Information This document (section 4.3.1)
34 SDH-ASON QoS Parameters This document (section 4.4.1)
40 LSP Protection Information This document (section 4.4.2)
6.3. PCEP RP Object Flag Field
IANA is requested to create a registry to manage the Flag field of
the RP object.
New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Name Flag
o Reference
Code space of the Flag field (RP object).
Bit Number Name Reference
0,1,2 Network Type (NT) This document (section 4.1)
6.4. PCEP NO-PATH-VECTOR TLV Flag Field
IANA is requested to create a registry to manage the Flag field of
the NO-PATH-VECTOR TLV.
New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Name Flag
o Reference
Zhang Expires July 2010 [Page 18]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
Code space of the Flag field (NO-PATH-VECTOR TLV).
Bit Number Name Reference
27 No Resource (NR) This document (section 4.2.1)
28 Protection Mismatch (PM) This document (section 4.2.1)
6.5. New PCEP Error Codes
As descried in Section 4.5, new PCEP Error-Type and Error Values are
defined. IANA is requested to manage the code space of the Error
object.
Error-Type Error-value
10 Reception of an invalid object
Error-value=2: Requested GMPLS Label information TLV
missing in RP object.
Error-value=3: LSP Protection Information TLV missing
in QoS object.
Error-value=4: TLV missing in QoS object.
Error-value=5: Multiple instance of TLV present in QoS
object.
Error-value=6: Unsupported TLV present in QoS object.
Error-value=7: SONET/SDH QoS parameters TLV missing in
QoS object.
14 Path computation failure
Error-value=1: Unacceptable response message.
Error-value=2: QoS object missing in request message.
7. Security Considerations
The protocol extensions defined in this document do not substantially
change the nature of PCEP. Therefore, the security considerations set
out in RFC5440 apply unchanged.
Zhang Expires July 2010 [Page 19]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
8. References
8.1. Normative References
[GMPLS-REQ] Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements
for GMPLS applications of PCE", July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3209] Bradner, S., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links
in Resource Reservation Protocol - Traffic Engineering
(RSVP-TE)", January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", May 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", May 2008.
8.2. Informative References
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", February 2003.
[RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element
(PCE)-Based Architecture", August 2006.
[RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", September
2006.
[RFC4674] Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", October 2006.
[RFC5088] Roux, J., "OSPF Protocol Extensions for PCE Discovery",
January 2008.
Zhang Expires July 2010 [Page 20]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
[RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE)
communication Protocol (PCEP)", March 2009.
9. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Email: zhangfatai@huawei.com
Suresh BR
Huawei Technologies
Shenzhen
China
Email: sureshbr@huawei.com
SenthilKumar S
Huawei Technologies
Shenzhen
China
Email: senthilkumars@huawei.com
Jun Sun
Huawei Technologies
Shenzhen
China
Email: sunjun@huawei.com
Intellectual Property
The IETF Trust 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 any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
Zhang Expires July 2010 [Page 21]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Zhang Expires July 2010 [Page 22]
draft-zhang-pce-pcep-extensions-for-sdh-00.txt January 2010
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhang Expires July 2010 [Page 23]