draft-ietf-ccamp-lsp-attribute-ro-00.txt | draft-ietf-ccamp-lsp-attribute-ro-01.txt | |||
---|---|---|---|---|
CCAMP C. Margaria, Ed. | CCAMP C. Margaria, Ed. | |||
Internet-Draft Nokia Siemens Networks | Internet-Draft Nokia Siemens Networks | |||
Intended status: Standards Track G. Martinelli | Intended status: Standards Track G. Martinelli | |||
Expires: August 11, 2013 Cisco | Expires: August 28, 2013 Cisco | |||
S. Balls | S. Balls | |||
B. Wright | B. Wright | |||
Metaswitch | Metaswitch | |||
February 07, 2013 | February 24, 2013 | |||
LSP Attribute in ERO | LSP Attribute in ERO | |||
draft-ietf-ccamp-lsp-attribute-ro-00 | draft-ietf-ccamp-lsp-attribute-ro-01 | |||
Abstract | Abstract | |||
LSP attributes can be specified or recorded for whole path, but they | LSP attributes can be specified or recorded for whole path, but they | |||
cannot be targeted to a specific hop. This document proposes | cannot be targeted to a specific hop. This document proposes | |||
alternative ways to extend the semantic for RSVP ERO object to target | alternative ways to extend the semantic for RSVP ERO object to target | |||
LSP attributes to a specific hop. | LSP attributes to a specific hop. | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 37 | skipping to change at page 1, line 37 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 11, 2013. | This Internet-Draft will expire on August 28, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 14 | skipping to change at page 2, line 14 | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 | 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. ERO LSP Attribute Subobject . . . . . . . . . . . . . . . . . 5 | |||
3.1. Non solution . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. ERO LSP_ATTRIBUTE subobject . . . . . . . . . . . . . . . 5 | |||
3.2. Extended ERO Object . . . . . . . . . . . . . . . . . . . 5 | 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. Semantic of the Extended ERO object . . . . . . . . . 5 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
3.2.3. Subobjects . . . . . . . . . . . . . . . . . . . . . . 6 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2.4. Processing . . . . . . . . . . . . . . . . . . . . . . 9 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | ||||
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
1. Introduction | 1. Introduction | |||
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched | Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched | |||
Paths (LSPs) can be route-constrained by making use of the Explicit | Paths (LSPs) can be route-constrained by making use of the Explicit | |||
Route (ERO) object and related sub-objects as defined in [RFC3209], | Route (ERO) object and related sub-objects as defined in [RFC3209], | |||
[RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. | [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. | |||
This document proposes mechanisms to target LSP attributes at a | Those route constraints are extended by a number of documents, | |||
specific hop. This document presents several solutions for | including element defined in [RFC6163], | |||
discussion, final document will contains only one document after WG | [I-D.ietf-ccamp-wson-signaling], | |||
consensus. | [I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] or | |||
[I-D.ali-ccamp-rc-objective-function-metric-bound]. | ||||
RSVP already supports generic extension of LSP attributes in | ||||
[RFC5420]. In order to support current and future ERO constraint | ||||
extensions this document defines a mechanism to target LSP attributes | ||||
at a specific hop. | ||||
1.1. Contributing Authors | 1.1. Contributing Authors | |||
1.2. Requirements Language | 1.2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2. Requirements | 2. Requirements | |||
The requirement is to provide a generic mechanism to carry | The requirement is to provide a generic mechanism to carry | |||
information related to specific nodes when signaling an LSP. This | information related to specific nodes when signaling an LSP. This | |||
document does not restrict what that information can be used for. | document does not restrict what that information can be used for. | |||
LSP attribute defined [RFC5420] should be expressed in ERO and SERO | LSP attribute defined [RFC5420] should be expressed in ERO and SERO | |||
objects. | objects. | |||
3. Solutions | 3. ERO LSP Attribute Subobject | |||
3.1. Non solution | ||||
A solution using a specific ERO or SERO subobject is not used because | ||||
the subobject length is limited to 8 bit, versus 16 bit for LSP | ||||
ATTRIBUTES. This does not allow to put LSP ATTRIBUTE subobjects in | ||||
ERO subobjects. | ||||
3.2. Extended ERO Object | ||||
The logic of the EXTENDED_EXPLICIT_ROUTE follows the one of SERO.The | ||||
class of the EXTENDED_EXPLICIT_ROUTE object is xxx (of the form | ||||
11bbbbbb). The EXTENDED_EXPLICIT_ROUTE object has the following | ||||
format: Class = xxx, C_Type = 1 The EXTENDED_EXPLICIT_ROUTE object | ||||
may be used if some node along the explicit route support this | ||||
object. The EXTENDED_EXPLICIT_ROUTE object is assigned a class value | ||||
of the form 11bbbbbb, so it is forwarded by nodes not supporting it. | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | ||||
// (Subobjects) // | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Subobjects The contents of an EXTENDED_EXPLICIT_ROUTE object are a | ||||
series of variable- length data items called subobjects. The | ||||
subobjects are defined in section Section 3.2.3 below. | ||||
3.2.1. Semantic of the Extended ERO object | ||||
Extended ERO object is carried in Path messages and carries a list of | ||||
hops extended with hop-specific information. It is structured as a | ||||
sequence of hop identifier subobjects (to indicate the hop who should | ||||
process the subsequent attributes) and a series of hop attributes | ||||
(which may be mandatory or optional) for the specified hop to | ||||
process. | ||||
3.2.2. Procedures | ||||
If a Path message contains multiple EXTENDED_EXPLICIT_ROUTE objects, | ||||
only the first object is meaningful. Subsequent | ||||
EXTENDED_EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be | ||||
propagated. An EXTENDED_EXPLICIT_ROUTE SHOULD contain at least 2 | ||||
subobjects. The first subobject MUST indicate a node or link that | ||||
identifies a hop that should process the next subobject(s). The | ||||
address used to identify the hop SHOULD also be listed in the ERO or | ||||
an SERO. This ensures that the extended attribute is for a node or | ||||
link along the LSP path. The second subobject SHOULD contains an | ||||
extended node or link information. In this document this SHOULD be a | ||||
LSP Attribute subobject. | ||||
3.2.3. Subobjects | ||||
The content of an EXTENDED_EXPLICIT_ROUTE are a series of variable | ||||
length subobjects. Each subobject has the following form | ||||
0 1 2 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------//-----------+ | ||||
| Type | Length | (Subobject contents)| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------//-----------+ | ||||
The Type indicates the type of contents of the subobject. Currently | ||||
defined values are: | ||||
1 Hop identifier subobject containing an ERO subobject: | ||||
IPv4 prefix | ||||
IPv6 prefix | ||||
Unnumbered Interface ID | ||||
Autonomous system number | ||||
Path Key with 32-bit PCE ID | ||||
Path Key with 128-bit PCE ID | ||||
Per-hop attributes: | ||||
XX LSP Attribute | ||||
Length The Length contains the total length of the subobject in | ||||
bytes, including the Type and Length . The Length MUST be at least | ||||
4, and MUST be a multiple of 4. | ||||
3.2.3.1. Hop identifier | ||||
The Hop identifier subobject contains exactly one ERO subobject | ||||
identifying a hop. The value of the subobject is a copy of the ERO | ||||
subobject definition. The format of the subobject 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 |L| sub Type | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sub Length | (Subobject contents) ... | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Type 0x01 Hop Identifier | ||||
Length The Length contains the total length of the subobject in | ||||
bytes, including the Type and Length fields. | ||||
Sub type The ERO subobject type, the same as the ERO subobject type. | ||||
the ERO type defined are : | ||||
1 IPv4 prefix | ||||
2 IPv6 prefix | ||||
3 Reserved | ||||
4 Unnumbered Interface ID | ||||
32 Autonomous system number | ||||
33 Reserved | ||||
37 Reserved | ||||
64 Path Key with 32-bit PCE ID | ||||
65 Path Key with 128-bit PCE ID | ||||
Sub length The ERO subobject type, the same as the ERO subobject | The ERO LSP Attributes subobject may be carried in the ERO or SERO | |||
length. It its unchanged compared to the ERO subobject | object if they are present. The subobject uses the standard format | |||
definition. | of an ERO subobject. | |||
Subobject contents The ERO subobject content, it its unchanged | 3.1. ERO LSP_ATTRIBUTE subobject | |||
compared to the ERO subobject definition. | ||||
3.2.3.2. Hop LSP Attribute | The length is variable and content MUST be the same as for the | |||
LSP_ATTRIBUTE object with Attributes TLVs. The size of the ERO sub- | ||||
object limits the size of the LSP Attribute TLV to 250 bytes. The | ||||
typical size of currently defined and forthcoming LSP_ATTRIBUTE TLVs | ||||
applicable to a specific hop (WSON_SIGNALING, OF and Metric) is not | ||||
foreseen to exceed this limit. | ||||
The LSP attribute subobject contains information targeted at the hop | The ERO LSP attribute subobject is defined as follows: | |||
identified by the preceding hop identifier subobject. | ||||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 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 | Reserved |R| | |L| Type | Length | Reserved |R| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// Attributes TLVs // | // Attributes TLVs // | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The attributes TLV are encoded as defined in [RFC5420] section 3. | See [RFC3209] for a description of L parameters. The attributes TLV | |||
are encoded as defined in [RFC5420] section 3. | ||||
Type x TBD by IANA. | Type x TBD by IANA. | |||
Length The Length contains the total length of the subobject in | Length The Length contains the total length of the subobject in | |||
bytes, including the Type and Length fields. The Length MUST be | bytes, including the Type and Length fields. The Length MUST be | |||
always divisible by 4. | always divisible by 4. | |||
Reserved Reserved, must be set to 0 when the subobject is inserted | Reserved Reserved, must be set to 0 when the subobject is inserted | |||
in the ERO, MUST NOT be changed when a node process the ERO and | in the ERO, MUST NOT be changed when a node process the ERO and | |||
must be ignored on the node addressed by the preceding ERO | must be ignored on the node addressed by the preceding ERO | |||
subobjects | subobjects. | |||
R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE | R This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE | |||
semantic. When set indicates required LSP attributes to be | semantic. When set indicates required LSP attributes to be | |||
processed by the node, when cleared the LSP attributes are not | processed by the node, when cleared the LSP attributes are not | |||
required as described in Section 3.2.3.3. | required as described in Section 3.2. | |||
3.2.3.3. Processing | Attributes TLVs as defined in [RFC5420] section 3. | |||
Following [RFC3209] and [RFC3473] the Extended ERO is managed as a | 3.2. Procedures | |||
list where each hop information starts with a subobject identifying | ||||
an abstract node or link. The LSP attribute subobject must be | As described in [RFC3209] and [RFC3473] the ERO is managed as a list | |||
appended after the hop identifier subobject (which follows the | where each hop information starts with a subobject identifying an | |||
formatting of the objects defined in [RFC3209], [RFC3473], [RFC3477], | abstract node or link. The LSP attribute subobject must be appended | |||
[RFC4873], [RFC4874], [RFC5520] and [RFC5553]. Several LSP attribute | after the existing subobjects defined in [RFC3209], [RFC3473], | |||
subobject MAY be present for each hop identification object. | [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. Several | |||
LSP attribute subobject MAY be present, for each hop. | ||||
If a node is processing an LSP attribute subobject and does not | ||||
support handling of the subobject it will behave as described in | ||||
[RFC3209] when an unrecognized ERO subobject is encountered. This | ||||
node will return a PathErr with error code "Routing Error" and error | ||||
value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object | ||||
included, truncated (on the left) to the offending unrecognized | ||||
subobject. | ||||
When the R bit is set a node MUST examine the attribute TLV present | When the R bit is set a node MUST examine the attribute TLV present | |||
in the subobject following the rules described in [RFC5420] section | in the subobject following the rules described in [RFC5420] section | |||
5.2. When the R bit is not set a node MUST examine the attribute TLV | 5.2. When the R bit is not set a node MUST examine the attribute TLV | |||
present in the subobject following the rules described in [RFC5420] | present in the subobject following the rules described in [RFC5420] | |||
section 4.2. If more than one ERO LSP attribute subobject having the | section 4.2. | |||
R bit set is present, the first one MUST be processed and the others | ||||
SHOULD be ignored. If more than one ERO LSP attribute subject having | ||||
the R bit cleared is present for the same hop identification object, | ||||
then the first one MUST be processed and the others SHOULD be | ||||
ignored. | ||||
3.2.4. Processing | ||||
A node receiving a Path message containing an EXTENDED_EXPLICIT_ROUTE | ||||
object must determine if the extended hop information is applicable | ||||
for this node. The node performs the following steps: | ||||
1. The node receiving the RSVP message MUST first evaluate if the | ||||
ERO object is present. If the ERO object is not present it has | ||||
received the message in error and SHOULD return a pathError | ||||
message. | ||||
2. Second the node MUST read the first subobject. If the node is | ||||
not part of the abstract node described by the first subobject, | ||||
the processing stops. | ||||
3. If there is no second subobject this indicates the end of the | ||||
extended ERO. The extended ERO SHOULD be removed from the Path | ||||
message. A new extended ERO MAY be added to the Path message. | ||||
4. Next the node evaluates the second subobject. | ||||
A. If the subobject identified an abstract node and the node is | ||||
also part of the abstract node, then the node deletes the | ||||
first subobject and continue processing with step 3. | ||||
B. If the subobject identified an abstract node and the node is | ||||
not part of the abstract node, then the extended ERO is | ||||
invalid and the node SHOULD return a PathErr with error code | ||||
"Routing Error" and error value "Bad EXTENDED_EXPLICIT_ROUTE | ||||
object" with the EXTENDED_EXPLICIT_ROUTE object included, | ||||
truncated (on the left) to the offending unrecognized | ||||
subobject | ||||
C. If the subobject is an LSP Attribute subobject it processes | ||||
it according to the rules for that subobject and removes it | ||||
from the extended ERO. If the extended ERO does not contain | ||||
further subject it SHOULD be removed from the Path message. | ||||
A new extended ERO MAY be added to the Path message. | ||||
If a node finds a hop identification object which matches the local | ||||
router handling of the subobject it will behave as described in | ||||
[RFC3209] when an unrecognized ERO subobject is encountered. This | A node processing an LSP attribute subobject with an LSP_ATTRIBUTE | |||
node will return a PathErr with error code "Routing Error" and error | TLV longer than the ERO subobject SHOULD return a PathErr with error | |||
value "Bad EXTENDED_EXPLICIT_ROUTE object" with the | code "Routing Error" and error value "Bad EXPLICIT_ROUTE object" with | |||
EXTENDED_EXPLICIT_ROUTE object included, truncated (on the left) to | the EXPLICIT_ROUTE object included, truncated (on the left) to the | |||
the offending unrecognized subobject. | offending malformed subobject. The processing of the LSP_ATTRIBUTE | |||
TLVs should be described in the documents defining them. | ||||
4. IANA Considerations | 4. IANA Considerations | |||
TBD once a final approach has been chosen. | TBD once a final approach has been chosen. | |||
5. Security Considerations | 5. Security Considerations | |||
None. | None. | |||
6. Acknowledgments | 6. Acknowledgments | |||
skipping to change at page 14, line 46 | skipping to change at page 10, line 46 | |||
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving | [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving | |||
Topology Confidentiality in Inter-Domain Path Computation | Topology Confidentiality in Inter-Domain Path Computation | |||
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. | Using a Path-Key-Based Mechanism", RFC 5520, April 2009. | |||
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource | [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource | |||
Reservation Protocol (RSVP) Extensions for Path Key | Reservation Protocol (RSVP) Extensions for Path Key | |||
Support", RFC 5553, May 2009. | Support", RFC 5553, May 2009. | |||
7.2. Informative References | 7.2. Informative References | |||
[I-D.ali-ccamp-rc-objective-function-metric-bound] | ||||
Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K., | ||||
and R. Kunze, "Resource ReserVation Protocol-Traffic | ||||
Engineering (RSVP-TE) extension for signaling Objective | ||||
Function and Metric Bound", | ||||
draft-ali-ccamp-rc-objective-function-metric-bound-02 | ||||
(work in progress), July 2012. | ||||
[I-D.dong-ccamp-rsvp-te-mpls-tp-li-lb] | ||||
Dong, J., Chen, M., and Z. Li, "GMPLS RSVP-TE Extensions | ||||
for Lock Instruct and Loopback", | ||||
draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 (work in | ||||
progress), December 2012. | ||||
[I-D.ietf-ccamp-wson-signaling] | ||||
Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H. | ||||
Harai, "Signaling Extensions for Wavelength Switched | ||||
Optical Networks", draft-ietf-ccamp-wson-signaling-05 | ||||
(work in progress), February 2013. | ||||
[I-D.kern-ccamp-rsvpte-hop-attributes] | [I-D.kern-ccamp-rsvpte-hop-attributes] | |||
Kern, A. and A. Takacs, "Encoding of Attributes of LSP | Kern, A. and A. Takacs, "Encoding of Attributes of LSP | |||
intermediate hops using RSVP-TE", | intermediate hops using RSVP-TE", | |||
draft-kern-ccamp-rsvpte-hop-attributes-00 (work in | draft-kern-ccamp-rsvpte-hop-attributes-00 (work in | |||
progress), October 2009. | progress), October 2009. | |||
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for | ||||
GMPLS and Path Computation Element (PCE) Control of | ||||
Wavelength Switched Optical Networks (WSONs)", RFC 6163, | ||||
April 2011. | ||||
Authors' Addresses | Authors' Addresses | |||
Cyril Margaria (editor) | Cyril Margaria (editor) | |||
Nokia Siemens Networks | Nokia Siemens Networks | |||
St Martin Strasse 76 | St Martin Strasse 76 | |||
Munich, 81541 | Munich, 81541 | |||
Germany | Germany | |||
Phone: +49 89 5159 16934 | Phone: +49 89 5159 16934 | |||
Email: cyril.margaria@nsn.com | Email: cyril.margaria@nsn.com | |||
End of changes. 21 change blocks. | ||||
224 lines changed or deleted | 90 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |