Network Working Group C. Margaria. C, Ed.
Internet-Draft E. Sfeir. E
Intended status: Standards Track F. Rambach. F
Expires: June 30, 2010 Nokia Siemens Networks
O. Gonzalez de Dios. O
F. Jimenez Chico. F.J.
Telefonica Investigacion y
Desarrollo
December 27, 2009
PCEP extensions for GMPLS
draft-margaria-pce-gmpls-pcep-extensions-00
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 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 June 30, 2010.
Copyright Notice
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
Margaria. C, et al. Expires June 30, 2010 [Page 1]
Internet-Draft PCEP Ext for GMPLS December 2009
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
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Margaria. C, et al. Expires June 30, 2010 [Page 2]
Internet-Draft PCEP Ext for GMPLS December 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. PCEP requirements . . . . . . . . . . . . . . . . . . . . 3
1.2. PCEP existing objects related to GMPLS . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 5
2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 6
2.2. Endpoints encoding . . . . . . . . . . . . . . . . . . . . 8
2.3. LABEL SET object . . . . . . . . . . . . . . . . . . . . . 10
2.4. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 11
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative References . . . . . . . . . . . . . . . . . . . 11
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Margaria. C, et al. Expires June 30, 2010 [Page 3]
Internet-Draft PCEP Ext for GMPLS December 2009
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 documents 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
is described in [I-D.ietf-pce-gmpls-aps-req] and
[I-D.ietf-pce-wson-routing-wavelength].
1.1. PCEP requirements
This section provides a set of PCEP requirements to support signal
compatibility constraints. 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.
(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]
Margaria. C, et al. Expires June 30, 2010 [Page 4]
Internet-Draft PCEP Ext for GMPLS December 2009
(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]
We describe in this document a proposal to fulfill those
requirements.
1.2. 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]:
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:
Margaria. C, et al. Expires June 30, 2010 [Page 5]
Internet-Draft PCEP Ext for GMPLS December 2009
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-unnumbered), 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.3. 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.
2. PCEP objects and extensions
This section describes the required PCEP objects and extensions. The
PCReq/PCRep message is defined in [RFC5440], with extensions
(GENERALIZED BANDWIDTH and LABEL Set)
Margaria. C, et al. Expires June 30, 2010 [Page 6]
Internet-Draft PCEP Ext for GMPLS December 2009
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>][<GENERALIZED-BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>][< GENERALIZED-BANDWIDTH>]
]
[<IRO>]
[<LABEL SET>]
[<LOAD-BALANCING>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
Where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>]
[<metric-list>]
[<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. Ctype 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.
Margaria. C, et al. Expires June 30, 2010 [Page 7]
Internet-Draft PCEP Ext for GMPLS December 2009
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
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 those objects MAY be included.
Margaria. C, et al. Expires June 30, 2010 [Page 8]
Internet-Draft PCEP Ext for GMPLS December 2009
2.2. Endpoints encoding
In GMPLS context the endpoints can:
o Be unnumbered
o Have label(s) associated to them
o May have different switching capabilities
The traffic type is expressed in the following objects/type:
o Endpoint label types (Enc, switch, gpid),
o TSPEC: Signal type
o SWITCH layer (enc, switching)
Only the TSPEC and SWITCH layer need to be coherent, the endpoint
labels could be different The PCE might know the node internal
adaptation capabilities, and handle the internal routing, but this is
not a requirement. Since the PCEP ENDPOINTS object does not support
unnumbered endpoints information, a new Ctype is proposed. In any
case the unnumbered interface id has to be encoded as an object new
Ctype. The proposed format is (generalized unnumbered interface id
endpoint):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Margaria. C, et al. Expires June 30, 2010 [Page 9]
Internet-Draft PCEP Ext for GMPLS December 2009
is possible to have in the future more than one object, so it is
better to have a dedicated subtlv for the label (the scope is then
more clear). TLVs are encoded as follow (following [RFC5440]) :
o Sub-TLV Label, Type = TBA by IANA, Length is variable, Encoding is
as follow:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|U|Label-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Sub-TLV Label Set, Type = TBA by IANA , Length is variable,
Encoding is as follow:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |I|U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A label subTlv 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
Margaria. C, et al. Expires June 30, 2010 [Page 10]
Internet-Draft PCEP Ext for GMPLS December 2009
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]
The I and U bits have the following meaning
I: Ingress bit, set when the label or label set is applicable to the
ingress endpoint
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enc. Type |Switching Type | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields and U bit are as defined in Section 2.2, See also
[RFC3471] and [RFC3473] for the definitions of the fields.
It is allowed to have more than one LABEL SET object per PCEReq (for
example in case of multiple SWITCH-LAYER present).
Margaria. C, et al. Expires June 30, 2010 [Page 11]
Internet-Draft PCEP Ext for GMPLS December 2009
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. 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
3. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
4. Security Considerations
None.
5. References
5.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.
Margaria. C, et al. Expires June 30, 2010 [Page 12]
Internet-Draft PCEP Ext for GMPLS December 2009
[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.
[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
(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.
Margaria. C, et al. Expires June 30, 2010 [Page 13]
Internet-Draft PCEP Ext for GMPLS December 2009
5.2. Informative References
[I-D.ietf-ccamp-ethernet-traffic-parameters]
Papadimitriou, D., "Ethernet Traffic Parameters",
draft-ietf-ccamp-ethernet-traffic-parameters-09 (work in
progress), November 2009.
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
Otani, T., Tsuritani, T., Li, D., Rabbat, R., Shiba, S.,
Guo, H., Miyazaki, K., and D. Caviglia, "Generalized
Labels for Lambda-Switching Capable Label Switching
Routers", draft-ietf-ccamp-gmpls-g-694-lambda-labels-05
(work in progress), December 2009.
[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]
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-00 (work in
progress), September 2009.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 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 June 30, 2010 [Page 14]
Internet-Draft PCEP Ext for GMPLS December 2009
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
Elie Sfeir
Nokia Siemens Networks
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16159
Email: elie.sfeir@nsn.com
Franz Rambach
Nokia Siemens Networks
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 31188
Email: franz.rambach@nsn.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3374013
Email: ogondio@tid.es
Margaria. C, et al. Expires June 30, 2010 [Page 15]
Internet-Draft PCEP Ext for GMPLS December 2009
Francisco Javier Jimenez Chico
Telefonica Investigacion y Desarrollo
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3379037
Email: fjjc@tid.es
Margaria. C, et al. Expires June 30, 2010 [Page 16]