draft-ietf-ccamp-path-key-ero-01.txt   draft-ietf-ccamp-path-key-ero-02.txt 
Networking Working Group R. Bradford
Internet-Draft JP. Vasseur Networking Working Group A. Farrel (Ed.)
Intended Status: Standards Track Cisco Systems, Inc. Internet-Draft Old Dog Consulting
Created: May 14, 2008 A. Farrel Intended Status: Standards Track R. Bradford
Expires: November 14, 2008 Old Dog Consulting Created: October 31, 2008 JP. Vasseur
Expires: April 30, 2009 Cisco Systems, Inc.
RSVP Extensions for Path Key Support RSVP Extensions for Path Key Support
draft-ietf-ccamp-path-key-ero-01.txt draft-ietf-ccamp-path-key-ero-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 39 skipping to change at page 1, line 40
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) The paths taken by Multiprotocol Label Switching (MPLS) and
Traffic Engineering (TE) Label Switched Paths (LSPs) may be Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
computed by Path Computation Elements (PCEs). Where the TE LSP Paths (LSPs) may be computed by Path Computation Elements (PCEs).
crosses multiple domains, such as Autonomous Systems (ASes), the Where the TE LSP crosses multiple domains, such as Autonomous Systems
path may be computed by multiple PCEs that cooperate, with each (ASes), the path may be computed by multiple PCEs that cooperate,
responsible for computing a segment of the path. To preserve with each responsible for computing a segment of the path.
confidentiality of topology within each AS, the PCE supports a
mechanism to hide the contents of a segment of a path, called the To preserve confidentiality of topology within each AS, the PCEs
Confidential Path Segment (CPS), by encoding the contents as a support a mechanism to hide the contents of a segment of a path (such
Path Key Subobject (PKS). as the segment of the path that traverses an AS), called the
Confidential Path Segment (CPS), by encoding the contents as a Path
Key Subobject (PKS) and embedding this subobject within the result of
its path computation.
This document describes how to carry Path Key Subobjects in the This document describes how to carry Path Key Subobjects in the
Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs)
and Record Route Object (RROs) so facilitate confiedntiality in the and Record Route Object (RROs) so as to facilitate confidentiality in
signaling of inter-domain TE LSPs. the signaling of inter-domain TE LSPs.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [RFC2119]. RFC-2119 [RFC2119].
1. Introduction 1. Introduction
skipping to change at page 2, line 31 skipping to change at page 2, line 36
Where the TE LSP crosses multiple domains [RFC4726], such as Where the TE LSP crosses multiple domains [RFC4726], such as
Autonomous Systems (ASes), the path may be computed by multiple PCEs Autonomous Systems (ASes), the path may be computed by multiple PCEs
that cooperate, with each responsible for computing a segment of the that cooperate, with each responsible for computing a segment of the
path. To preserve confidentiality of topology with each AS, the path. To preserve confidentiality of topology with each AS, the
PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to
hide the contents of a segment of a path, called the Confidential hide the contents of a segment of a path, called the Confidential
Path Segment (CPS), by encoding the contents as a Path Key Path Segment (CPS), by encoding the contents as a Path Key
Subobject (PKS) [PCE-PKS]. Subobject (PKS) [PCE-PKS].
This document defines RSVP-TE protocol extensions necessary to This document defines RSVP-TE protocol extensions necessary to
support the use of Path Key Segments in MPLS and GMPLS signaling. support the use of Path Key Subobjects in MPLS and GMPLS signaling by
including them in Explicit Route Objects (EROs) and Record Route
Object (RROs) so as to facilitate confidentiality in the signaling of
inter-domain TE LSPs.
1.1. Usage Scenario 1.1. Usage Scenario
Figure 1 shows a simple network constructed of two ASes. An LSP is Figure 1 shows a simple network constructed of two ASes. An LSP is
desired from the Ingress in Domain-1 to the Egress in Domain-2. As desired from the ingress in AS-1 to the egress in AS-2. As described
described in [RFC4655], the Ingress Label Switching Router (LSR) acts in [RFC4655], the ingress Label Switching Router (LSR) acts as a Path
as a Path Computation Client (PCC) and sends a request to its PCE Computation Client (PCC) and sends a request to its PCE (PCE-1).
(PCE-1). PCE-1 can compute the path within Domain-1, but has no PCE-1 can compute the path within AS-1, but has no visibility into
visiblity into Domain-2. So PCE-1 cooperates with PCE-2 to complete AS-2. So PCE-1 cooperates with PCE-2 to complete the path
the path computation. computation.
However, PCE-2 does not want to share the information about the However, PCE-2 does not want to share the information about the
path across Domain-2 with nodes outside the domain. So, as described path across AS-2 with nodes outside the AS. So, as described in
in [PCE-PKS], PCE-2 reports the Domain-2 path segment using a Path [PCE-PKS], PCE-2 reports the AS-2 path segment using a PKS rather
Key Subobject rather than the details of the path. than the explicit details of the path.
PCE-1 can now return the path to be signaled to the Ingress LSR in a PCE-1 can now return the path to be signaled to the ingress LSR in a
path computation response with the Domain-2 segment still hidden as a path computation response with the AS-2 segment still hidden as a
Path Key Segment. PKS.
In order to set up the LSP, the Ingress LSR signals using RSVP-TE and In order to set up the LSP, the ingress LSR signals using RSVP-TE and
encodes the path reported by PCE-1 in the Explicit Route Object encodes the path reported by PCE-1 in the Explicit Route Object
(ERO). This process is as normal for RSVP-TE, but requires that the (ERO). This process is as normal for RSVP-TE, but requires that the
PKS is also included in the ERO using the mechanisms defined in this PKS is also included in the ERO using the mechanisms defined in this
document. document.
When the signaling message (the RSVP-TE Path message) reaches ASBR-2 When the signaling message (the RSVP-TE Path message) reaches ASBR-2
it consults PCE-2 to 'decode' the PKS. (The information about which it consults PCE-2 to 'decode' the PKS and return the expanded
PCE to use to decode the PKS is encoded within the PKS.) The PKS is explicit path segment to ASBR-2. (The information that PCE-2 uses to
replaced in the ERO with the expanded information about the path. decode the PKS is encoded within the PKS itself.) The PKS is replaced
in the ERO with the expanded information about the path.
----------------------------- ---------------------------- ----------------------------- ----------------------------
| Domain-1 | | Domain-2 | | AS-1 | | AS-2 |
| | | | | | | |
| ------- | | ------- | | ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | | | | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- | | ------- | | ------- |
| ^ | | ^ | | ^ | | ^ |
| | | | | | | | | | | |
| v | | v | | v | | v |
| ------- ---- | | ---- | | ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ | | | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| | | |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
skipping to change at page 3, line 48 skipping to change at page 4, line 12
route based on a network graph and applying computational route based on a network graph and applying computational
constraints. constraints.
PKS: Path Key Subobject. A subobject of an Explicit Route Object PKS: Path Key Subobject. A subobject of an Explicit Route Object
which encodes a CPS, so as to preserve confidentiality. which encodes a CPS, so as to preserve confidentiality.
3. RSVP-TE Path Key Subobject 3. RSVP-TE Path Key Subobject
The Path Key Subobject (PKS) may be carried in the Explicit Route The Path Key Subobject (PKS) may be carried in the Explicit Route
Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a fixed- Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a fixed-
length subobject containing a Path-Key and a PCE-ID. The Path Key is length subobject containing a Path Key and a PCE-ID. The Path Key is
an identifier, or token used to represent the CPS within the context an identifier, or token used to represent the CPS within the context
of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE
that can decode the Path Key using a reachable IPv4 or IPv6 address that can decode the Path Key using a reachable IPv4 or IPv6 address
of the PCE. In most cases, the decoding PCE is also the PCE that of the PCE. In most cases, the decoding PCE is also the PCE that
computed the Path Key and the associated path. Because of the IPv4 computed the Path Key and the associated path. Because of the IPv4
and IPv6 variants, two subobjects are defined as follows. and IPv6 variants, two subobjects are defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 36 skipping to change at page 6, line 7
address that is restricted to the domain in which the LSR that is address that is restricted to the domain in which the LSR that is
called upon to expand the CPS lies. Other values that have no called upon to expand the CPS lies. Other values that have no
meaning outside the domain (for example, the IPv6 TE Router ID) meaning outside the domain (for example, the IPv6 TE Router ID)
MAY be used to increase security (see Section 5). MAY be used to increase security (see Section 5).
Note: The twins of these sub-objects are carried in PCEP messages Note: The twins of these sub-objects are carried in PCEP messages
as defined in [PCE-PKS]. as defined in [PCE-PKS].
3.1. Explicit Route Object Processing Rules 3.1. Explicit Route Object Processing Rules
This section to be completed in a future release. The basic processing rules of an ERO are not altered. Refer to
[RFC3209] for details. In particular, an LSR is not required to "look
ahead" in the ERO beyond the first subobject that is non-local.
3.2. Reporting Path Key Segments in Record Route Objects [PCE-PKS] requires that any path fragment generated by a PCE that
contains a PKS is such that the PKS is immediately preceded by an
subobject that identifies the head end of the PKS (for example, an
incoming interface, or a node ID). This rule is extended to the PKS
in the ERO so that the following rules are defined.
This section to be completed in a future release. - If an LSR receives a Path message where the first subobject of the
ERO is a PKS, it MUST respond with a PathErr message carrying the
error code/value combination "Routing Problem"/"Bad initial
subobject".
4. Security Considerations - If an LSR strips all local sub-objects from an ERO carried in a
Path message (according to the procedures in [RFC3209]) and finds
that the next subobject is a PKS it MUST attempt to resolve the PKS
to a CPS.
- Confidentiality of the CPS (can other network elements probe for Resolution of the PKS MAY take any of the following forms or use
expansion of path-keys, possibly at random?). some other technique subject to local policy and network
implementation.
- Authenticity of the path-key (resilience to alteration by - The LSR can use the PCE-ID contained in the PKS to contact the
intermediaries, resilience to fake expansion of path-keys). identified PCE using PCEP [PCEP] and request that the PKS be
expanded.
- Resilience from DNS attacks (insertion of spurious path-keys; - The LSR can contact any PCE using PCEP [PCEP] to request that the
flooding of bogus path-key expansion requests). PKS be expanded relying on cooperation between the PCEs.
Most of the interactions required by this extension are point to - The LSR can use the information in the PKS to index a CPS
point, can be authenticated and made secure as described in [PCEP] previously supplied to it by the PCE that originated the PKS.
and [RFC3209]. These interactions are listed in [PCE-PKS]
Thus, the major security issues can be dealt with using standard If a CPS is derived, the path fragment SHOULD be inserted into the
techniques for securing and authenticating point-to-point ERO of the Path message as a direct replacement for the PKS. Other
communications. In addition, it is recommended that the PCE processing of the CPS and ERO are permitted as described in
providing a decode response should check that the LSR that issued [RFC3209].
the decode request is the head end of the decoded ERO segment.
This processing can give rise to the following error cases:
- PCE-ID cannot be matched to a PCE to decode the PKS.
The LSR sends a PathErr message with the error code "Routing
Problem" and a new error value "Unknown PCE-ID for PKS expansion"
(see Section 6.3).
- PCE identified by the PCE-ID cannot be reached.
The LSR sends a PathErr message with the error code "Routing
Problem" and a new error value "Unreachable PCE for PKS
expansion" (see Section 6.3).
- The PCE is unable to decode the PKS, perhaps because the Path Key
has expired.
The LSR sends a PathErr message with the error code "Routing
Problem" and a new error value "Unknown Path Key for PKS
expansion" (see Section 6.3).
- PKS cannot be decoded for policy reasons.
The LSR sends a PathErr message with the error code "Policy
Control Failure" and a the error value "Inter-domain policy
failure".
- Addition of CPS to ERO causes Path message to become too large.
The LSR MAY replace part of the ERO with loose hops [RFC3209] or
with a further PKS according to local policy if the loss in
specifics within the explicit path is acceptable. If the LSR is
unable to take steps to reduce the size of the ERO it MUST send a
PathErr message with the error code "Routing Problem" and a new
error value "ERO too large for MTU" (see Section 6.3).
- An LSR that is called on to process a PKS within an ERO, but does
not recognize the subobject will react according to [RFC3209] and
send a PathErr message with the error code/value combination
"Routing Problem"/"Bad Explicit Route Object".
3.2. Reporting Path Key Segments in Record Route Objects
The Record Route Object (RRO) is used in RSVP-TE to record the route
traversed by an LSP. The RRO may be present on a Path message and on
a Resv message. The intention [RFC3209] is that an RRO on a Resv
message received by an ingress LSR is suitable for use as an ERO on a
Path message sent by that LSR to achieve an identical LSP.
The PKS offers an alternative that can be more useful to diagnostics.
When the signaling message crosses a domain boundary, the path
segment that needs to be hidden (that is, a CPS) MAY be replaced in
the RRO with a PKS. In the case of an RRO on a Resv message, the PKS
used SHOULD be the one originally signaled in the ERO of the Path
message. On a Path message, the PKS SHOULD identify the LSR replacing
the CPS, and provide a Path Key that can be used to expand the path
segment. In the latter case, the Path Key and its expansion SHOULD be
retained by the LSR that performs the substitution for at least the
lifetime of the LSP. In both cases, the expansion of the PKS SHOULD
be made available to diagnostic tools under the control of local
policy.
4. Security Considerations
The protocol interactions required by the mechanisms described in
this document are point to point and can be authenticated and made
secure as described in [PCEP] and [RFC3209]. The protocol
interactions for PCEP are listed in [PCE-PKS], while general
considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can
be found in [MPLS-SEC].
Thus, the security issues can be dealt with using standard techniques
for securing and authenticating point-to-point communications. In
addition, it is RECOMMENDED that the PCE providing a PKS expansion
checks that the LSR that issued the request for PKS expansion is the
head end of the resulting CPS.
Further protection can be provided by using a PCE ID to identify Further protection can be provided by using a PCE ID to identify
the decoding PCE that is only meaningful within the domain that the decoding PCE that is only meaningful within the domain that
contains the LSR at the head of the CPS. This may be an IP address contains the LSR at the head of the CPS. This may be an IP address
that is only reachable from within the domain, or some not-address that is only reachable from within the domain, or some non-address
value. The former requires configuration of policy on the PCEs, value. The former requires configuration of policy on the PCEs,
the latter requires domain-wide policy. the latter requires domain-wide policy.
The following specific security issues need to be considered.
- Confidentiality of the CPS. The question to be answered is whether
other network elements can probe for a PCE for the expansion of
PKSs, possibly generating path keys at random. This can be
protected against by only allowing PKS expansion to be successfully
completed if requested by the LSR that is at the head end of the
resulting CPS. Under specific circumstances, PKS expansion might
also be allowed by configured management stations.
The CPS itself may be kept confidential as it is exchanged in the
PCEP and RSVP-TE protocols using standard security mechanisms
defined for those protocols.
- Determination of information by probing. In addition to the probing
described above, a node might deduce information from the error
responses generated when PKS expansion fails as described in
Section 3.1. Any LSR that considers that supplying one of the
detailed error codes described in Section 3.1 might provide too
much information that could be used as part of a systematic attack,
MAY simply use the error code/value "Policy Control Failure"/
"Inter-domain policy failure" in all cases.
- Authenticity of the path key. A concern is that the path key in the
PKS will be altered or faked leading to erroneous path key
expansion and the use of the wrong CPS. The consequence would be a
bad ERO in a Path message causing the LSP to be set up incorrectly
resulting in incorrect network resource usage, diversion of traffic
to where it can be intercepted, or failure to set up the LSP. These
problems can be prevented by protecting the protocol exchanges in
PCEP and RSVP-TE using standard security techniques.
- Resilience to DNS attacks. A PCE can be attacked through a flood of
path key expansion requests - this issue is addressed in [PCE-PKS]
and is out of scope for this document. A further attack might
consist of sending a flood of RSVP-TE Path messages with
deliberately spurious PKSs. This attack is prevented by ensuring
the integrity of the Path messages using standard RSVP-TE security
mechanisms, and by enforcing the RSVP-TE chain of trust security
model.
5. Manageability Considerations 5. Manageability Considerations
5.1. Control of Function Through Configuration and Policy 5.1. Control of Function Through Configuration and Policy
Policy forms an important part of the use of PKSs in EROs and RROs.
There are local and domain-wide policies that SHOULD be available for
configuration in an implementation.
- Handling of an ERO containing a PKS. As described in Section 3.1 an
LSR that receives a Path message containing a PKS can be configured
to reject the Path message according to policy.
- Handling of PKS requests at a PCE. As described in Section 3.1, in
[PCE-PKS], and in [PCE-POLICY] a PCE can be configured with policy
about how it should handle requests for PKS expansion.
- PKS expansion. Section 3.1 explains that the PKS can be expanded by
the local LSR, the specific PCE identified in the PKS, any PCE
acting as a proxy, or by some other method. The behavior of the LSR
needs to be locally configurable, but is subject the domain-wide
policy.
- Interpretation of PCE-ID. The interpretation of the PCE-ID
component of PKSs is subject to domain-local policy and needs to be
configurable as such. See Section 3 and Section 4 for the options.
- ERO too large. The behavior of an LSR when it finds that adding a
CS to the ERO causes the Path message to be too large, is an
implementation choice. However, implementations may choose to
provide configuration of behavior as described in Section 3.1.
- Masking of RRO. As described in Section 3.2, a border router can
choose to mask segments of the path by replacing them with PKSs.
This behavior needs to be configurable with the default being to
not hide any part of the RRO.
- Inspection / decode of PKS by diagnostic tools. A PCE can allow
access from management or diagnostic tools to request the expansion
of a PKS. Note that this must be regulated with the security and
confidentiality behavior described in Section 4.
- Hiding of reason codes. An LSR can support the configuration of
local policy to hide reason codes associated with the failure to
expand a PKS, and as described in Section 4, report all errors as
policy failures.
The treatment of a path segment as a CPS, and its substitution in The treatment of a path segment as a CPS, and its substitution in
a PCReq ERO with a PKS, is a function that SHOULD be under a PCReq ERO with a PKS, is a PCE function and is described in
operator and policy control where a PCE supports the function. The [PCE-PKS].
operator SHOULD be given the ability to specify which path
segments are to be replaced and under what circumstances. For
example, an operator might set a policy that states that every
path segment for the operator's domain will be replaced by a PKS
when the PCReq has been issued from outside the domain.
6. IANA considerations 6. IANA considerations
The IANA section will be detailed in further revision of this 6.1. Explicit Route Object Subobjects
document.
It will include code point requests for the three new ERO sub- IANA maintains a registry called "Resource Reservation Protocol
objects, and a new ErrorSpec Error Code. (RSVP) Parameters" with a subregistry called "Class Names, Class
Numbers, and Class Types".
Note: The twins of these sub-objects are be carried in PCEP Within this subregistry there is a definition of the EXPLICIT_ROUTE
messages as defined in [PCE-PKS]. Ideally, IANA assignment of the object with Class Number 20. The object definition lists a number of
subobject types will be identical. acceptable sub-objects for the Class Type 1.
IANA is requested to allocate two further sub-objects as described in
Section 3. The resulting entry in the registry should look as
follows.
20 EXPLICIT_ROUTE [RFC3209]
Class Types or C-Types:
1 Type 1 Explicit Route [RFC3209]
Sub-object type
64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D]
Note well: [PCE-PKS] defines the PKS for use in PCEP. IANA is
requested to assign the same sub-object numbers for use in RSVP-TE as
are assigned for the PKS in PCEP. The numbers suggested above are the
same as are suggested in [PCE-PKS].
6.2. Record Route Objects Subobjects
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Class Names, Class
Numbers, and Class Types".
Within this subregistry there is a definition of the ROUTE_RECORD
object (also known as the RECORD_ROUTE object) with Class Number 21.
The object definition lists a number of acceptable sub-objects for
the Class Type 1.
IANA is requested to allocate two further sub-objects as described in
Section 3. The resulting entry in the registry should look as
follows.
21 ROUTE_RECORD [RFC3209]
(also known as RECORD_ROUTE)
Class Types or C-Types:
1 Type 1 Route Record [RFC3209]
Sub-object type
64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D]
Note well: IANA is requested to use the same sub-object numbers as
are defined for the EXPLICIT_ROUTE object in Section 6.1.
6.3. Error Codes and Error Values
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes".
Within this subregistry there is a definition of the "Routing
Problem" error code with error code value 24. The definition lists a
number of error values that may be used with this error code.
IANA is requested to allocate further error values for use with this
error value as described in Section 3.1. The resulting entry in the
registry should look as follows.
24 Routing Problem [RFC3209]
This Error Code has the following globally-defined Error
Value sub-codes:
31 = Unknown PCE-ID for PKS expansion [This.ID]
32 = Unreachable PCE for PKS expansion [This.ID]
33 = Unknown Path Key for PKS expansion [This.ID]
34 = ERO too large for MTU [This.ID]
The values shown above are suggested values.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",
RFC3473, January 2003. RFC3473, January 2003.
7.2. Informational References 7.2. Informational References
[PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS
Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Networks", draft-ietf-mpls-mpls-and-gmpls-security-
Element (PCE) communication Protocol (PCEP)", framework, work in progress.
draft-ietf-pce-pcep, work in progress.
[PCEP] J.P. Vasseur, et al., "Path Computation Element (PCE)
Communication Protocol (PCEP)", draft-ietf-pce-pcep, work
in progress.
[PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving
Topology Confidentiality in Inter-Domain Path Computation Topology Confidentiality in Inter-Domain Path Computation
Using a Key-Based Mechanism", draft-ietf-pce-path-key, Using a Key-Based Mechanism", draft-ietf-pce-path-key,
work in progress. work in progress.
[PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, G.,
"Policy-Enabled Path Computation Framework", draft-ietf-
pce-policy-enabled-path-comp, work in progress.
[RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation
Element (PCE) Architecture", RFC 4655, August 2006. Element (PCE) Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
8. Authors' Addresses: 8. Authors' Addresses:
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Rich Bradford Rich Bradford
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
Email: rbradfor@cisco.com Email: rbradfor@cisco.com
J.-P Vasseur J.-P Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 32 change blocks. 
78 lines changed or deleted 327 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/