Internet DRAFT - draft-bitar-zhang-interas-pcecp-reqs
draft-bitar-zhang-interas-pcecp-reqs
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
Network Working Group Nabil Bitar (Editor)
Verizon
Internet Draft Raymond Zhang (Editor)
BT Infonet
Kenji Kumaki (Editor)
KDDI Corporation
Expires: December 2006 June 2006
Inter-AS Requirements for the Path Computation Element Communication
Protocol (PCECP)
draft-bitar-zhang-interas-pcecp-reqs-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that 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 becomes
aware will be disclosed, in accordance with Section 6 of 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 in December 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Bitar et al. Inter-AS Requirements for PCECP [Page 1]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
Abstract
This document discusses requirements for the support of the Path
Computation Element Communication Protocol (PCECP) in inter-AS
applications. Its main objective is to present a set of requirements
which would result in guidelines for the definition, selection and
specification development for any technical solution(s) meeting these
requirements.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents
1. Introduction.....................................................2
2. Definitions......................................................3
3. Reference Model..................................................4
4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4
4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............4
4.1.1.1. Requirements on path computation requests..................4
4.1.1.2. Requirements on path computation responses.................6
4.1.2. Scalability and Performance Requirements.....................6
4.1.3. Management, Aliveness Detection and Recovery Requirements....7
4.1.4. Confidentiality..............................................8
4.1.5. Policy Controls Effecting inter-AS PCECP.....................8
4.1.5.1. Inter-AS PCE Peering Policy Controls.......................8
4.1.5.2. Inter-AS PCE Reinterpretation Polices......................9
5. Security Considerations..........................................9
6. IANA Considerations..............................................9
7. Acknowledgments..................................................9
8. Authors' Addresses...............................................9
9. Normative References............................................10
10. Informative References.........................................10
1.
Introduction
MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]
defined the scenarios motivating the deployment of inter-AS MPLS
traffic engineering. [INTERAS-TE-REQ] also specified the requirements
for inter-AS MPLS traffic engineering when the ASes are under one
Service Provider (SP) administration or the administration of
different SPs.
Today, there are three signaling options in setting up an inter-AS
TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2)
Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE
LSP as in [LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines
mechanisms for inter-domain path computation using network elements
along the signaling and data paths. The mechanisms in [INTERD-TE-
Bitar, Zhang et al. [Page 2]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
PDPC] do not provide the capability to guarantee an optimum TE path
across multiple ASes. A (G)MPLS-TE optimum path for an LSP is one
that has the smallest cost, according to a normalized TE metric
(based upon a TE-metric or IGP metric adopted in each transit AS),
among all possible paths that satisfy the LSP TE-constraints.
The requirements for a PCE have risen from SP needs to compute a more
optimum path than that can be achieved by mechanisms provided in
[INTERD-TE-PDPC], and be able to separate the path computation
elements from the forwarding elements.
Generic requirements for the PCE discovery protocol (PCEDP) and
PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP-
REQ] and [PCECP-REQ], respectively. Complementary to these already-
defined generic requirements, this document provides a set of PCECP
requirements that are specific to (G)MPLS-TE inter-AS path
computation using a PCE-based approach.
Section 2 of this document states some definitions. Section 3 defines
a reference model. Section 4 states inter-AS PCECP requirements.
Section 5 discusses security issues.
2.
Definitions
This document adopts the definitions and acronyms defined in
[INTERAS-TE-REQ] Section 3.1 and [PCE-ARCH] Section 2. In addition,
we use the following terminology:
PCECP: PCE Communication Protocol
PCEDP: PCE Discovery Protocol
Inter-AS (G)MPLS-TE path: A (G)MPLS-TE path that traverses two or
more ASes
Intra-AS (G)MPLS-TE path: A (G)MPLS-TE path that is confined to a
single AS. It may traverse on or more IGP areas.
Inter-area PCE: A PCE responsible for computing (G)MPLS-TE paths or
path segments traversing across multi-IGP areas.
Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths
traversing a single AS.
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-
TE paths or path segments, by possibly cooperating with intra-AS
PCEs, across one or more ASes.
Bitar, Zhang et al. [Page 3]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
3.
Reference Model
Figure 1 depicts the reference model for PCEs in an inter-AS
application. We refer to two types of PCE functions in this document:
inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures
needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs
perform the functions needed for intra-AS (G)MPLS-TE path
computation. This document focuses on the PCE Communication Protocol
requirements used by inter-AS PCEs to communicate path
requests/responses to other inter-AS PCEs and by intra-AS PCEs to
communicate path requests/responses to inter-AS PCEs and vice versa.
Inter-AS Inter-AS Inter AS
PCE1<---------->PCE2<--------------> PCE3
:: :: ::
R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | |
| | | | | |
R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
::
Intra-AS
PCE
<==AS1=> <====AS2======> <=====AS3===>
Figure 1 Inter and Intra-AS PCE Reference Model
4.
Detailed PCECP Requirements for Inter-AS (G)MPLS-TE
This section discusses detailed PCECP requirements for inter-AS
(G)MPLS-TE applications using a PCE-based approach. Depending on the
operation environment, service providers may use some or all of the
capabilities of a PCECP that satisfies these requirements.
Specifically, some requirements are more applicable to inter-AS
inter-provider (G)MPLS-TE operation than intra-provider operations.
4.1.1.
PCC/PCE-PCE Communication Protocol Requirements
Requirements specific to inter-AS PCECP path computation requests
and responses are discussed in section 4.1.1.1 and 4.1.1.2,
respectively.
4.1.1.1.
Requirements on path computation requests
Bitar, Zhang et al. [Page 4]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
Following are inter-AS specific requirements on PCECP requests for
path computation
- PCECP MUST allow the specification of a path computation request
priority as specified in [PCECP-REQ]. Priority-based message
processing is a local decision to a PCE and is out of the scope of
this document. However, in inter-AS operation, a policy may be
enforced on a path computation request so that the path computation
request priority is altered when progressing the request within the
same AS or across other ASes. PCECP SHOULD allow the notification of
the requester of such a change when it happens. Such notification MAY
be suppressed by configuration action on a neighboring inter-AS PCE
basis.
- A path computation request to an inter-AS PCE MUST be able to
specify ASBRs and/or ASes as strict and loose nodes in the path of
the LSP to the destination. A PCE MUST also be able to specify a
preferred ASBR for exiting to the next AS for reaching the
destination through a neighboring AS. If such a constraint cannot
be satisfied at a PCE, PCECP SHOULD allow a PCE to notify the
requestor of that fact in the path error message.
- PCECP MUST enable enlisting a list of ASes and/or ASBRs to be
excluded in the path computation.
- PCECP MUST enable an inter-AS PCE to specify the AS on whose behalf
it is sending the request. This is specifically important when the
inter-AS PCE has identified many ASes within its scope to the other
inter-AS PCE at the other end of the communication.
- A PCC or PCE (including inter-AS PCE) MUST be able to specify in
its PCECP path computation request the need for computing an end-to-
end path with protection against node, link, and/or SRLG
failure using 1:1 detours or facility backup. An inter-AS PCE may
itself ask for a similarly protected path. In addition, it may ask
for protection across all ASes the path can traverse or across
specific ASes.
- A PCC or PCE MUST be able to specify in its path request to an
inter-AS PCE the retturn of a minimum of two diversified paths
(i.e., paths that do not share common nodes, links and/or SRLGs).
- A PCECP path computation request message MUST enable the
specification of AS-only diversified path computation.
- A PCECP path computation request message MUST be able to identify
the scope of diversified path computation to be end-to-end (i.e.,
between the endpoints of the (G)MPLS-TE tunnel) or to be limited to a
specific AS.
Bitar, Zhang et al. [Page 5]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
4.1.1.2.
Requirements on path computation responses
Following are inter-AS specific requirements on PCECP responses for
path computation:
- A path computation response MUST be able to include ASBRs and ASes
on the computed path. In inter-AS intra-provider path
computation, there may not be any confidentiality issues or
restrictions that prevent one AS from returning a path with strict
hops and no loose hops (i.e., nodes and links) within its AS to the
requesting inter-AS PCE. In this case, the head-end of an LSP could
receive, as a result of the work of multiple cooperating intra-AS and
inter-AS PCEs, a path that contains nodes and links as strict hops
from LSP head-end to tail-end. In the inter-provider case,
confidentially and security considerations may require only the
return of AS numbers and/or ASBRs in path computation response
messages.
- A PCECP response message MUST be able to carry an identifier for a
path segment computed by the responding PCE. Such an identifier could
be used in a (G)MPLS-TE path setup message for path expansion at an
ASBR.
- A PCECP response message MUST be able to carry an inter-AS
path cost. Path cost normalization across ASes is out
of the scope of this document and it is expected to be addressed
in other work on path computation.
- A PCECP response message SHOULD be able to carry an intra-AS cost
for a path segment separately from an inter-AS path segment cost.
Best path selection procedures based on these costs are out of the
scope of this document.
- A PCECP response message MUST be able to identify diversified paths
for the same(G)MPLS-TE LSP when the responding PCE is requested to
compute such paths. End-to-end (i.e., between the two endpoints of
the (G)MPLS-TE tunnel) disjoint diversified paths are paths that do
not share nodes, links or SRLGs except for the LSP head-end and tail-
end. In cases where diversified path segments are desired within one
or more ASes, the diversified path segments may share only the ASBRs
of the first AS and the ASBR of the last AS across these ASes.
4.1.2.
Scalability and Performance Requirements
When evaluating a PCECP for the inter-AS case, the following
scalability and performance criteria SHOULD be considered:
- Message Processing load on the inter-AS PCEs and intra-AS PCEs.
- Scalability as a function of the following parameters:
Bitar, Zhang et al. [Page 6]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
- number of PCCs within the scope of an inter-AS PCE
- number of intra-area PCEs within the scope of an inter-AS PCE
- number of peering inter-AS PCEs
- Added complexity and features to the PCC/PCE-PCE communication
protocol
4.1.3.
Management, Aliveness Detection and Recovery Requirements
[PCECP-REQ] specifies generic requirements for PCECP management. This
document addresses new requirements that apply to inter-AS
operations.
The PCECP MIB module MUST provide objects to control the behavior of
PCECP in inter-AS applications, including the ASes within its scope,
the ASes the PCE cannot communicate with via PCECP, the ASes that the
PCE can communicate with, confidentiality policies, and traffic
engineering policies. Each of these two latter requirements SHOULD
apply per inter-AS PCE and/or AS peer.
The built-in diagnostic tools MUST enable failure detection and
status checking of PCC/PCE-PCE PCECP. Diagnotic tools include
statistics collection on the historical behavior of PCECP as
specified in [PCECP-REQ]. For inter-AS operations, this statistics
SHOULD be collected on per inter-AS PCE peer basis and per AS. For
instance, the following statistics SHOULD be collected:
- number of successfully satisfied requests
- number of rejected requests per reason
- number of PCE requests
- number of malformed PCECP messages
- number of unauthenticated PCECP messages
The MIB module MUST support trap functions when thresholds are
crossed or when important events occur for inter-AS PCEs. These
thresholds SHOULD be specifiable per peer AS as well as per peer
inter-AS PCE and traps should be accordingly generated.
Basic liveliness detection for PCC/PCE-PCE communication is described
in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to
check the liveliness of the neighboring inter-AS PCE(s) it is
communicating with for inter-AS (G)MPLS-TE path computation. The
inter-AS PCECP MIB module SHOULD allow control of liveliness check
behavior by providing a liveliness message frequency MIB object. This
frequency SHOULD be specified per inter-AS PCE peer. In addition,
there SHOULD a MIB object that specifies the dead-interval as a
multiplier of the liveliness message frequency so that if no
liveliness message is received within that time from an inter-A PCE,
the inter-AS PCE is declared unreachable.
Bitar, Zhang et al. [Page 7]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
4.1.4.
Confidentiality
Confidentiality mainly applies to inter-provider PCE communication.
However, confidentiality rules may also apply among ASes under a
single provider. Each SP will in most cases designate some PCEs for
inter-AS (G)MPLS-TE path computation within its own administrative
domain and some other PCEs for inter-provider inter-As (G)MPLS-TE
path computation. Among the inter-provider-scoped inter-AS PCEs in
each SP domain, there may also be a subset of the PCEs specifically
enabled for path computation across a specific set of ASes of
different peer SPs.
PCECP SHOULD allow an SP to hide from other SPs the set of hops,
within its own AS(es,) traversed by an inter-AS inter-provider
(G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a
multi-SP administrative domain environment, SPs want to hide their
network topologies for security reasons. In addition, SPs do not want
to reveal the path traversed by an LSP segment within their domains
to other SPs' domains. Thus, for each partial inter-AS LSP path a PCE
computes, it may return to its peering PCE in the upstream neighbor
AS(es) an inter-AS TE LSP segment from its own AS(es) without
detailing the explicit intra-AS hops plus partial paths with an
aggregated TE LSP cost it receives from its downstream PCE. As stated
earlier, PCECP responses SHOULD be able to carry path-segment
identifiers without the details of that path segment. An ASBR that
receives an RSVP-TE path message with an identifier object
(new object), it can use that object to contact the PCE keyed by
that identifier and extract the identified path segment as well.
4.1.5.
Policy Controls Effecting inter-AS PCECP
Section 5.2.2 of [INTERAS-TE-REQ] discusses the policy control
requirements on the inter-AS RSVP-TE signaling at the AS boundaries
for the enforcement of interconnect agreements, attribute/parameter
translation and security hardening.
This section discusses those policy control requirements for PCECP.
Please note that SPs may still require ingress policy controls on the
actual signaling paths mentioned above to enforce their bilateral or
multi-lateral agreements at the AS boundaries.
4.1.5.1.
Inter-AS PCE Peering Policy Controls
In a multi-SP administrative domain environment, each SP itself has
some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends
path computation requests with some parameters to its neighboring
inter-AS PCEs. An inter-AS PCE that receives such requests enforces
some policies applied to its neighboring inter-AS PCEs. These
policies may include rewriting some of the parameters' values and
rejecting requests based on some parameters' values. Such policies
may also be applied in the case of multiple ASes within a single SP
Bitar, Zhang et al. [Page 8]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
administrative domain. Parameters subject to policy include
bandwidth, setup/holding priority, Fast Reroute request,
Differentiated Services Traffic Engineering (DS-TE) Class Type (CT),
and others as specified in section 5.2.2.1 of [INTERAS-TE-REQ].
For path computation requests that are not compliant with configured
policies, PCECP SHOULD enable a PCE to send an error message to the
requesting PCC or PCE indicating the cause of errors.
4.1.5.2.
Inter-AS PCE Reinterpretation Polices
Each SP may have different definitions in its use of for example,
RSVP-TE session attributes, DS-TE TE classes, etc. A PCE receiving
path computation requests needs to be able to reinterpret some of the
attributes and adapt them to the native environment in its own AS for
path computation. A list of such parameters subject to policy
reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ].
In addition, the transit SPs along the inter-AS TE path may be GMPLS
transport providers which may require reinterpretation of MPLS
specific PCECP path request messages for path computation over a
GMPLS network. These interpretation policies must be specifiable on
a per-peer inter-AS PCE or AS basis as part of PCECP MIBs discussed
earlier.
5.
Security Considerations
Security concerns arise between any two communicating elements
especially when the elements belong to different administrative
entities. In this case, there are security concerns that need to be
addressed for communication among inter-AS PCEs and other PCEs in a
single SP administrative domain as well among inter-AS PCEs under
different SP administrative domains. [PCECP-REQ] specifies
requirements on PCECP to protect against spoofing, snooping and DoS
attacks. These requirements become especially important in the multi-
AS case.
6.
IANA Considerations
This document makes no requests for IANA action.
7.
Acknowledgments
We would like to thank Adrian Farrel, Jean-Philippe Vasseur,
and Jean Louis Le Roux for their useful comments and suggestions.
8.
Authors' Addresses
Nabil Bitar
Bitar, Zhang et al. [Page 9]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
Verizon
40 Sylvan Road
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com
Raymond Zhang
BT INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com
9.
Normative References
[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
Engineering Requirements", RFC4216, November 2005.
[PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element
(PCE) Based Architecture", draft-ietf-pce-architecture-05.txt
(Work in Progress).
[PCECP-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol
Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-
06.txt (work in progress).
10.
Informative References
[INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-
rsvp-te-02.txt, April 2006 (Work in Progress)
[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,
September 2005, (work in progress).
[LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)
Hierarchy with Generalized MPLS TE", RFC4206, October 2005.
[PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation
Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in
progress).
Bitar, Zhang et al. [Page 10]
Internet Draft draft-bitar-zhang-interas-pcecp-reqs-01 June 2006
[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
computation method for computing Inter-domain Traffic Engineering
(TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
path-comp-02.txt, February 2006, (Work in Progress).
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Bitar, Zhang et al. [Page 11]
