Network Working Group C. Margaria. C, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track O. Gonzalez de Dios. O, Ed.
Expires: January 2, 2011 Telefonica Investigacion y
Desarrollo
F. Zhang. F, Ed.
Huawei Technologies
July 01, 2010
PCEP extensions for GMPLS
draft-margaria-pce-gmpls-pcep-extensions-01
Abstract
This memo provides extensions for the Path Computation Element
communication Protocol (PCEP) for the support of GMPLS control plane.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 2, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Margaria. C, et al. Expires January 2, 2011 [Page 1]
Internet-Draft PCEP Ext for GMPLS July 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3
1.3. PCEP existing objects related to GMPLS . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6
2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 7
2.2. END-POINTS Object extensions . . . . . . . . . . . . . . . 8
2.2.1. Generalized endpoint Object Type . . . . . . . . . . . 9
2.2.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 11
2.3. LABEL SET object . . . . . . . . . . . . . . . . . . . . . 13
2.4. SUGGESTED LABEL SET object . . . . . . . . . . . . . . . . 14
2.5. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 14
2.6. NO-PATH Object Extension . . . . . . . . . . . . . . . . . 15
2.6.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . . 15
3. Additional Error Type and Error Values Defined . . . . . . . . 16
4. Manageability Considerations . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 19
5.3. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Margaria. C, et al. Expires January 2, 2011 [Page 2]
Internet-Draft PCEP Ext for GMPLS July 2010
1. Introduction
PCEP RFCs [RFC5440], [RFC5521], [RFC5541], [RFC5520] are focused on
path computation requests in MPLS networks. [RFC4655] defines the
PCE framework also for GMPLS networks. This document complements
these RFCs by providing some consideration of GMPLS applications and
routing requests, for example for OTN and WSON networks.
The requirements on PCE extensions to support those characteristics
are described in [I-D.ietf-pce-gmpls-aps-req] and
[I-D.ietf-pce-wson-routing-wavelength].
1.1. Contributing Authors
Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier
Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR,
Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon
Casellas (CTTC)
1.2. PCEP requirements for GMPLS
This section provides a set of PCEP requirements to support GMPLS
LSPs and assure signal compatibility in the path. When requesting a
path computation (PCReq) to PCE, the PCC should be able to indicate,
according to [I-D.ietf-pce-gmpls-aps-req], the following additional
attributes:
(1) Switching capability: PSC1-4, L2SC, TDM, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g.,
Ethernet, SONET/SDH, Lambda, etc.
(3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with
different granularity have been defined in SONET/SDH and G.709
ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2
and ODU3 in G.709 ODUk [RFC4606] and [RFC4328].
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous concatenation
which requires co-route for each member signal and requires all
the interfaces along the path to support this capability, and
virtual concatenation which allows diverse routes for the member
signals and only requires the ingress and egress interfaces to
support this capability. Note that for the virtual concatenation,
it also may specify co-routed or separated-routed. See [RFC4606]
and [RFC4328] about concatenation information.
Margaria. C, et al. Expires January 2, 2011 [Page 3]
Internet-Draft PCEP Ext for GMPLS July 2010
(5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328].
(6) Wavelength Label: as defined in
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Link Protection type: as defined in [RFC4203]
(9) Support for unnumbered interfaces: as defined in [RFC3477]
(10) Support for asymmetric bandwidth request
We describe in this document a proposal to fulfill those
requirements.
1.3. PCEP existing objects related to GMPLS
PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext],
supports the following information (in the PCReq and PCRep) related
to the described RSVP-TE information.
From [RFC5440]:
o numbered endpoints
o bandwidth (float)
o ERO
o LSP attribute (setup and holding priorities)
o Request attribute (include some LSP attributes)
From [RFC5521]:
o Extensions to PCEP for Route Exclusions define a XRO object and a
new semantic (F bit): Fail bit indicating that the existing route
is failed and resources present in the RRO can be reused. This
object also allows to exclude (strict or not) resources; XRO
include the diversity level (node, link, SRLG). The requested
diversity is expressed in the XRO.
From [I-D.ietf-pce-inter-layer-ext]:
Margaria. C, et al. Expires January 2, 2011 [Page 4]
Internet-Draft PCEP Ext for GMPLS July 2010
o INTER-LAYER : indicates if inter-layer computation is allowed
o SWITCH-LAYER : indicates which layer(s) should be considered, can
be used to represent the RSVP-TE generalized label request
o REQ-ADAP-CAP : indicates the adaptation capabilities requested,
can also be used for the endpoints in case of mono-layer
computation
The shortcomings of the existing PCEP information are:
BANDWIDTH does not describe the details of the signal (for example
NVC, multiplier) in the context of TDM or OTN networks.
END-POINTS does not allow specifying an unnumbered interface, nor
the labels on the interface. Those parameters are of interest in
case of switching constraints.
Current attributes do not allow to express the requested link level
protection and end-to-end protection attributes.
In order to improve the PCEP, a new object is introduced
(GENERALIZED-BANDWIDTH) , a new object type is introduced for the
END-POINTS object (generalized-endpoint), and a TLV is added to the
LSPA object. In order to allow to restrict the range of labels
returned, an additional object is added : LABEL SET
1.4. 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 RFC 2119.
Margaria. C, et al. Expires January 2, 2011 [Page 5]
Internet-Draft PCEP Ext for GMPLS July 2010
2. PCEP objects and extensions
This section describes the required PCEP objects and extensions. The
PCReq and PCRep messages are defined in [RFC5440]. The format of the
request and response messages with the proposed extensions
(GENERALIZED BANDWIDTH, SUGGESTED LABEL SET and LABEL Set) is as
follows:
<request>::= <RP>
<end-point-rro-pair-list>
[<LSPA>]
[<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>][<GENERALIZED-BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<SUGGESTED LABEL SET>]
[<LABEL SET>]
[<LOAD-BALANCING>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>]
[< GENERALIZED-BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>]
[<metric-list>]
Margaria. C, et al. Expires January 2, 2011 [Page 6]
Internet-Draft PCEP Ext for GMPLS July 2010
[<IRO>]
2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH
The PCEP BANDWIDTH does not describe the details of the signal (for
example NVC, multiplier), hence the bandwidth information should be
extended to use the RSVP Tspec. The PCEP BANDWIDTH object defines
two types: 1 and 2. C-Type 2 is representing the existing bandwidth
in case of re-optimization.
The following possibilities cannot be represented in the BANDWIDTH
object:
o Asymmetric bandwidth (different bandwidth in forward and reverse
direction), as described in [RFC5467]
o Optical (SDH/SONET, G.709, ATM, MEF etc) parameters are not
supported.
We propose to add a new Object named GENERALIZED-BANDWIDTH having the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Spec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits R and O have the following meaning:
O bit : set when the value refer to the previous bandwidth in case
of re-optimization
R bit : set when the value refer to the bandwidth of the reverse
direction
The Object type determine which type of bandwidth is represented by
the object. The Following object type are defined:
1. Intserv
2. SONET/SDH
3. G.709
Margaria. C, et al. Expires January 2, 2011 [Page 7]
Internet-Draft PCEP Ext for GMPLS July 2010
4. Ethernet MEF (see [I-D.ietf-ccamp-ethernet-traffic-parameters])
The encoding of the field Traffic Spec is the same as in RSVP-TE, it
can be found in the following references.
Object Type Name Reference
2 Intserv [RFC2210]
4 SONET/SDH [RFC4606]
5 G.709 [RFC4328]
6 (TBA by Ethernet [I-D.ietf-ccamp-ethernet-traffic-parameters]
IANA) MEF
Traffic Spec field encoding
The GENERALIZED-BANDWIDTH MAY appear more than once in a PCReq
message. If more than one GENERALIZED-BANDWIDTH have the same Object
Type, Reserved, R and O values, only the first one is processed, the
others are ignored. On the response the TLVs that were considered in
the processing SHOULD.
When a PCC needs to get a bi-directional path with asymmetric
bandwidth, it should specify the different bandwidth in forward and
reverse directions through two separate GENERALIZED-BANDWIDTH
objects. The PCE needs to compute a path that satisfies the
asymmetric bandwidth constraint and return the path to PCC if the
path computation is successful.
2.2. END-POINTS Object extensions
The END-POINTS object is used in a PCReq message to specify the
source and destination of the path for which a path computation is
requested. From [RFC3471] source IP address and the destination IP
address are used to identify those. A new Object Type is defined to
address the following possibilities:
o Possibility to have different endpoint types.
o Label restrictions on the endpoint.
o Specification of unnumbered endpoints type as seen in GMPLS
networks.
The Object encoding is described in the following sections.
Margaria. C, et al. Expires January 2, 2011 [Page 8]
Internet-Draft PCEP Ext for GMPLS July 2010
2.2.1. Generalized endpoint Object Type
In GMPLS context the endpoints can:
o Be unnumbered
o Have label(s) associated to them
o May have different switching capabilities
The IPV4 and IPV6 endpoint are used to represent the source and
destination IP addresses. The scope of the IP address (Node or Link)
is not explicitly stated. It should also be possible to request a
Path between an numbered link and a unnumbered link, or a P2MP path
between different type of endpoints.
Since the PCEP ENDPOINTS object only support endpoint of the same
type a new C-Type are proposed that support different endpoint types,
including unnumbered endpoint. This New C-Type also support the
specification of constraints on the endpoint label to be use. The
PCE might know the interface restrictions but this is not a
requirement. On the path calculation request only the TSPEC and
SWITCH layer need to be coherent, the endpoint labels could be
different (supporting a different TSPEC). Hence the label
restrictions include a Generalized label request in order to
interpret the labels.
The proposed object format consists of a body and a list of TLVs with
the following defined TLVs (described in Section 2.2.2).
1. IPV4 address.
2. IPV6 address.
3. Unnumbered endpoint.
4. Label request.
5. Label.
6. Label set.
7. Suggested label set.
The Object is encoded as follow:
Margaria. C, et al. Expires January 2, 2011 [Page 9]
Internet-Draft PCEP Ext for GMPLS July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| endpoint type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the endpoint type is defined as follow:
Value Type Meaning
0 Point-to-Point
1 Point-to-Multipoint New leaves to add
2 Old leaves to remove
3 Old leaves whose path can be
modified/reoptimized
4 Old leaves whose path must be left
unchanged
The TLVs present in the object body should follow the following :
<generalized-endpoint-tlvs>::=
<endpoint> ; -- Source endpoint
[<endpoint-restrictions>]
<endpoint> [<endpoint-restrictions>]
[<endpoint> [<endpoint-restrictions>] ...]
For endpoint type Point-to-Point the first endpoint and optional
endpoint-restriction is the ingress endpoint. The second endpoint
and optional endpoint-restriction is the egress endpoint The further
endpoint and endpoint-restriction are ignored
For endpoint type Point-to-Multipoint the first endpoint and optional
endpoint-restriction is the source endpoint. The further endpoint
and endpoint-restriction are the leaves.
An endpoint is defined as follow:
Margaria. C, et al. Expires January 2, 2011 [Page 10]
Internet-Draft PCEP Ext for GMPLS July 2010
<endpoint>::=<IPV4_ADDRESS>|<IPV6_ADDRESS>|<UNNUMBERED_ENDPOINT>
<endpoint-restrictions> ::= <LABEL_REQUEST><label-restriction>
[<endpoint-restrictions>]
<label-restriction> ::= ((<LABEL><UPSTREAM_LABEL>)|
<LABEL_SET>|
<SUGGESTED_LABEL_SET>)
[<label-restriction>]
2.2.2. END-POINTS TLVs extensions
2.2.2.1. IPV4_ADDRESS
The format of the END-POINTS TLV object for IPv4 (TLV-Type=To be
assigned) 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.2.2. IPV6_ADDRESS TLV
The format of the END-POINTS TLV object for IPv6 (TLV-Type=To be
assigned) 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.2.3. UNNUMBERED_ENDPOINT TLV
This TLV represent an unnumbered interface. This TLV has the same
semantic as in [RFC3477]
Margaria. C, et al. Expires January 2, 2011 [Page 11]
Internet-Draft PCEP Ext for GMPLS July 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.2.4. LABEL_REQUEST sub-tlv
The LABEL-REQUEST indicate the and encoding of the LABEL restriction
present in the ENDPOINTS its format is the same as described in
[RFC3471] Section 3.1 Generalized label request
2.2.2.5. Labels sub-tlv
Label or label range may be specified for the TE-LSP endpoints.
Those are encoded in the sub-TLVs. The label value cannot be
interpreted without a description on the Encoding and switching type.
The REQ-ADAP-CAP object from [I-D.ietf-pce-inter-layer-ext] can be
used in case of mono-layer request, however in case of multilayer it
is possible to have in the future more than one object, so it is
better to have a dedicated TLV for the label (the scope is then more
clear). TLVs are encoded as follow (following [RFC5440]) :
o LABEL Sub-TLV, Type = TBA by IANA, Length is variable, Encoding is
as [RFC3471] Section 3.2 Generalized label. This represent the
downstream label
o UPSTEAM-LABEL Sub-TLV , Type = TBA by IANA, Length is variable,
Encoding is as [RFC3471] Section 3.2 Generalized label. This
represent the upstream label
o LABEL_SET Sub-TLV, Type = TBA by IANA , Length is variable,
Encoding follow :[RFC3471] Section 3.5 Label set with the addition
of a U bit, the U bit is set for upstream direction in case of
bidirectional LSP.
Margaria. C, et al. Expires January 2, 2011 [Page 12]
Internet-Draft PCEP Ext for GMPLS July 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SUGGESTED-LABEL_SET Sub-TLV Set, Type = TBA by IANA, Length is
variable, Encoding is as Label Set.
A label Sub-TLV represent the label used on the unnumbered interface,
bits I and U are used to indicate which exact unnumbered interface/
direction is considered. the fields are encoded as in the RSVP-TE.
The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE
etc., that will be used with the data associated with the LSP. The
Switching type indicates the type of switching that is being
requested on the link. G-PID identifies the payload of the TE-LSP.
The label type indicates which type of label (2) for generalized
label is carried. A Label Set Sub-TLV represents a set of possible
labels that can be used on the unnumbered interface. The action
parameter in the Label set indicates the type of list provided.
Those parameters are described by [RFC3471] A Suggested Label Set
Sub-TLV has the same encoding as the Label Set Sub-TLV, it represent
the order preferred set of label to be used
The U bit has the following meaning:
U: Upstream direction: set when the label or label set is in the
reverse direction
2.3. LABEL SET object
The LABEL SET object is carried within a PCReq message to restrict
the set of labels to be assigned during the routing. Any label
included in the ERO object on the response must comply with the
restrictions stated in the LABEL SET, whose encoding is defined as
Margaria. C, et al. Expires January 2, 2011 [Page 13]
Internet-Draft PCEP Ext for GMPLS July 2010
following
<LABEL-SET-OBJECT> ::= <LABEL-REQUEST><LABEL-SET>[<LABEL-SET>]
The LABEL-REQUEST and LABEL-SET TLV are as defined in
Section 2.2.2.5, See also [RFC3471] and [RFC3473] for the definitions
of the fields.
It is allowed to have more than one LABEL SET object per PCReq (for
example in case of multiple SWITCH-LAYER present).
In the case of unsuccessful path computation, the PCRep message also
contains a NO-PATH object, and the LABEL SET object MAY be used to
indicate the set of constraint that could not be satisfied.
2.4. SUGGESTED LABEL SET object
The SUGGESTED LABEL SET object is carried within a PCReq message to
indicate the preferred set of labels to be assigned during the
routing. The encoding is the same as the LABEL SET object. It is
allowed to have more than one SUGGESTED LABEL SET object per PCReq
(for example in case of multiple SWITCH-LAYER present).
2.5. LSPA extensions
The LSPA carries the LSP attributes. In the end-to-end protection
context this also includes the protection state information. The
LSPA object can be extended by a protection TLV type: Type TBA by
IANA: protection attribute
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is as defined in [RFC4872], [RFC4873].
LSP Flags can be considered for routing policy based on the
protection type. The other attributes are only meaningful for a
stateful PCE.
Margaria. C, et al. Expires January 2, 2011 [Page 14]
Internet-Draft PCEP Ext for GMPLS July 2010
2.6. 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 NO-PATH object
carries the NO-PATH-VECTOR TLV that specifies more information on the
reasons that led to a negative reply. In case of GMPLS 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.
2.6.1. Extensions to NO-PATH-VECTOR TLV
The current NO-PATH-VECTOR TLV carry the following information:
Bit number 31 - PCE currently unavailable [RFC5440]
Bit number 30 - Unknown destination [RFC5440]
Bit number 29 - Unknown source [RFC5440]
Bit number 28 - BRPC Path computation chain unavailable [RFC5440]
Bit number 27 - PKS expansion failure [RFC5520]
Bit number 26 - No GCO migration path found [RFC5557]
Bit number 25 - No GCO solution found [RFC5557]
Bit number 24 - P2MP Reachability Problem [RFC5440]
The modified NO-PATH-VECTOR TLV carrying the additional information
is as follows: New fields PM and NR are defined in the 23th and 22th
bit of the Flags field respectively.
Bit number 23 (TBA by IANA) - Protection Mismatch (1-bit).
Specifies the mismatch of the protection type in the request.
Bit number 22 (TBA by IANA) - No Resource (1-bit). Specifies that
the resources are not currently sufficient to provide the path.
Margaria. C, et al. Expires January 2, 2011 [Page 15]
Internet-Draft PCEP Ext for GMPLS July 2010
3. 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
Error-value=:1 Bad Generalized Bandwidth Object value.
Error-value=:2 Unsupported LSP Protection Type in
protection attribute TLV.
Error-value=:3 Unsupported LSP Protection Flags in
protection attribute TLV.
Error-value=:4 Unsupported Secondary LSP Protection
Flags in protection attribute TLV.
Error-value=:5 Unsupported Link Protection Type in
protection attribute TLV.
Error-value=:6 Unsupported Link Protection Type in
protection attribute TLV.
14 Path computation
failure
Error-value=1: Unacceptable response message.
Error-value=2: Generalized bandwidth object not
supported.
Error-value=3: Label Set constraint could not be met.
Error-value=4: Label constraint could not be met.
Error-value=5: Unsupported endpoint type in END-POINTS
GENERALIZED-ENDPOINTS object type
Margaria. C, et al. Expires January 2, 2011 [Page 16]
Internet-Draft PCEP Ext for GMPLS July 2010
Error-value=6: Unsupported TLV present in END-POINTS
GENERALIZED-ENDPOINTS object type
Margaria. C, et al. Expires January 2, 2011 [Page 17]
Internet-Draft PCEP Ext for GMPLS July 2010
4. 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].
Margaria. C, et al. Expires January 2, 2011 [Page 18]
Internet-Draft PCEP Ext for GMPLS July 2010
5. 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.
5.1. PCEP Objects
As described in Section 2.1 a new Object is defined IANA is requested
to make the following Object-Type allocations from the "PCEP Objects"
sub-registry:
Object Class to be assigned
Name GENERALIZED-BANDWIDTH
Object-Type 1
Reference This document (section Section 2.1)
As described in Section 2.2.1 a new Object type is defined IANA is
requested to make the following Object-Type allocations from the
"PCEP Objects" sub-registry:
Object Class 4
Name END-POINTS
Object-Type 5 : Generalized Endpoint
6-15 : unassigned
Reference This document (section Section 2.1)
5.2. New PCEP TLVs
IANA is requested to create a registry for the following TLVs:
Margaria. C, et al. Expires January 2, 2011 [Page 19]
Internet-Draft PCEP Ext for GMPLS July 2010
Value Meaning Reference
x IPV4 endpoint This document (section
Section 2.2.2.1)
x IPV6 endpoint This document (section
Section 2.2.2.2)
x Unnumbered endpoint This document (section
Section 2.2.2.3)
x Label request This document (section
Section 2.2.2.4)
x Requested GMPLS Label This document (section
Section 2.2.2.5)
x Requested GMPLS Upstream This document (section
Label Section 2.2.2.5)
x Requested GMPLS Label Set This document (section
Section 2.2.2.5)
x Suggested GMPLS Label Set This document (section
Section 2.2.2.5)
x LSP Protection Information This document (section Section 2.5)
5.3. New PCEP Error Codes
As described in Section Section 3, new PCEP Error-Type and Error
Values are defined. IANA is requested to manage the code space of
the Error object.
Margaria. C, et al. Expires January 2, 2011 [Page 20]
Internet-Draft PCEP Ext for GMPLS July 2010
Error-Type Error-value
10 Reception of an
invalid object
Error-value=:1 Bad Generalized Bandwidth Object value.
Error-value=:2 Unsupported LSP Protection Type in
protection attribute TLV.
Error-value=:3 Unsupported LSP Protection Flags in
protection attribute TLV.
Error-value=:4 Unsupported Secondary LSP Protection
Flags in protection attribute TLV.
Error-value=:5 Unsupported Link Protection Type in
protection attribute TLV.
Error-value=:6 Unsupported Link Protection Type in
protection attribute TLV.
14 Path computation
failure
Error-value=1: Unacceptable response message.
Error-value=2: Generalized bandwidth object not
supported.
Error-value=3: Label Set constraint could not be met.
Error-value=4: Label constraint could not be met.
Error-value=5: Unsupported endpoint type in END-POINTS
GENERALIZED-ENDPOINTS object type
Error-value=6: Unsupported TLV present in END-POINTS
GENERALIZED-ENDPOINTS object type
Margaria. C, et al. Expires January 2, 2011 [Page 21]
Internet-Draft PCEP Ext for GMPLS July 2010
6. Security Considerations
None.
Margaria. C, et al. Expires January 2, 2011 [Page 22]
Internet-Draft PCEP Ext for GMPLS July 2010
7. Contributing Authors
Nokia Siemens Networks:
Elie Sfeir
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16159
Email: elie.sfeir@nsn.com
Franz Rambach
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 31188
Email: franz.rambach@nsn.com
Francisco Javier Jimenez Chico
Telefonica Investigacion y Desarrollo
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3379037
Email: fjjc@tid.es
Huawei Technologies
Suresh BR
Shenzhen
China
Email: sureshbr@huawei.com
Young Lee
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
SenthilKumar S
Shenzhen
China
Email: senthilkumars@huawei.com
Margaria. C, et al. Expires January 2, 2011 [Page 23]
Internet-Draft PCEP Ext for GMPLS July 2010
Jun Sun
Shenzhen
China
Email: johnsun@huawei.com
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Ramon Casellas
PMT Ed B4 Av. Carl Friedrich Gauss 7
08860 Castelldefels (Barcelona)
Spain
Phone: (34) 936452916
Email: ramon.casellas@cttc.es
Margaria. C, et al. Expires January 2, 2011 [Page 24]
Internet-Draft PCEP Ext for GMPLS July 2010
8. Acknowledgments
The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar
Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these
results has received funding from the European Community's Seventh
Framework Programme FP7/2007-2013 under grant agreement n. 247674.
Margaria. C, et al. Expires January 2, 2011 [Page 25]
Internet-Draft PCEP Ext for GMPLS July 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
Margaria. C, et al. Expires January 2, 2011 [Page 26]
Internet-Draft PCEP Ext for GMPLS July 2010
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
9.2. Informative References
[I-D.ietf-ccamp-ethernet-traffic-parameters]
Papadimitriou, D., "Ethernet Traffic Parameters",
draft-ietf-ccamp-ethernet-traffic-parameters-10 (work in
progress), January 2010.
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
Otani, T., Rabbat, R., Shiba, S., Guo, H., Miyazaki, K.,
Caviglia, D., Li, D., and T. Tsuritani, "Generalized
Labels for Lambda-Switching Capable Label Switching
Routers", draft-ietf-ccamp-gmpls-g-694-lambda-labels-07
(work in progress), April 2010.
[I-D.ietf-pce-gmpls-aps-req]
Otani, T., Ogaki, K., Caviglia, D., and F. Zhang,
"Document: draft-ietf-pce-gmpls-aps-req-01.txt",
draft-ietf-pce-gmpls-aps-req-01 (work in progress),
July 2009.
[I-D.ietf-pce-inter-layer-ext]
Oki, E., Takeda, T., Roux, J., and A. Farrel, "Extensions
to the Path Computation Element communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-ext-03 (work in
progress), September 2009.
[I-D.ietf-pce-wson-routing-wavelength]
Margaria. C, et al. Expires January 2, 2011 [Page 27]
Internet-Draft PCEP Ext for GMPLS July 2010
Lee, Y., Bernstein, G., Martensson, J., Takeda, T., and T.
Tsuritani, "PCEP Requirements for WSON Routing and
Wavelength Assignment",
draft-ietf-pce-wson-routing-wavelength-01 (work in
progress), March 2010.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 5467, March 2009.
Margaria. C, et al. Expires January 2, 2011 [Page 28]
Internet-Draft PCEP Ext for GMPLS July 2010
Authors' Addresses
Cyril Margaria (editor)
Nokia Siemens Networks
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com
Oscar Gonzalez de Dios (editor)
Telefonica Investigacion y Desarrollo
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3374013
Email: ogondio@tid.es
Fatai Zhang (editor)
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen, 518129
P.R.China
Email: zhangfatai@huawei.com
Margaria. C, et al. Expires January 2, 2011 [Page 29]