inter-AS TE links.
5.1.11. Extensibility
The solution(s) MUST allow extensions as both inter-AS MPLS TE and
current intra-AS MPLS TE specifications evolve.
5.1.12. Complexity and Risks
The proposed solution(s) SHOULD NOT introduce unnecessary complexity
to the current operating network to such a degree that it would
affect the stability and diminish the benefits of deploying such a
solution over SP networks.
5.1.13. Backward Compatibility
The deployment of inter-AS MPLS TE SHOULD NOT impact existing BGP-
based traffic engineering or MPLS TE mechanisms, but allow for a
smooth migration or co-existence.
5.1.14. Performance
The solution SHOULD be evaluated taking into account various
performance criteria:
- Degree of path optimality of the inter-AS TE LSP path
- TE LSP setup time
- Failure and restoration time
- Impact and scalability of the control plane due to added
overheads, etc.
- Impact and scalability of the data/forwarding plane due to added
overheads, etc.
5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains
The requirements for inter-AS MPLS TE across multiple SP admin
domains SHOULD include all requirements discussed in section 5.1
above in addition to those that are presented in this section here.
Please note that the SP with multi-AS networks may choose not to turn
on the features discussed in the following two sections when building
TE tunnels across ASes in its own domain.
5.2.1. Confidentiality
Since an inter-AS TE LSP may span multiple ASes belonging to
different SPs, the solution MIGHT allow hiding the set of hops used
by the TE LSP within an AS, as illustrated in the following example:
[ ASBR1-----ASBR2 ]
[ ] [ ]
[ A ] [ B ]
[ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ]
[ ] [ ]
Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B
(within AS2 of SP2). When computing an inter-AS TE LSP path, the set
of hops within AS2 might be hidden to AS1. In this case, the
solution will allow A to learn that the more optimal TE LSP path to B
(that complies with the set of constraints) traverses ASBR2, without
a detailed knowledge of the lists of hops used within AS2.
Optionally, the TE LSP path cost within AS2 could be provided to A
via, for example, PCC-PCE communication, such that A (PCC) could use
this information to compute an optimal path, even if the computed
path is not provided by AS2. (See [PCE-COM] for PCC-PCE
communication and [PCE] for a description of the PCE-based path
computation architecture.)
In addition, the management requirements discussed in section 5.1.10
above, when used across different SP admin domains, SHOULD include
similar confidentiality requirements discussed here in terms of
"hiding" intermediate hops or interface address and/or labels in the
transiting or peering SPs.
5.2.2. Policy Control
In some cases, policy control might be necessary at the AS
boundaries, namely ingress policy controls enabling SPs to enforce
the inter-AS policies per interconnect agreements or to modify some
requested parameters conveyed by incoming inter-AS MPLS TE signaling
requests.
It is worth noting that such a policy control mechanism may also be
used between ASes within a SP.
This section discusses only the elements that may be used to form a
set of ingress control policies, but exactly how SPs establish
bilateral or multilateral agreements upon which the control policies
can be built is beyond the scope of this document.
5.2.2.1. Inter-AS TE Agreement Enforcement Polices
The following provides a set of TE-LSP parameters in the inter-AS TE
Requests (RSVP Path Message) that could be enforced at the AS
boundaries:
- RSVP-TE session attributes: affinities and preemption priorities
- Per AS or SP bandwidth admission control to ensure that RSVP-TE
messages do not request for bandwidth resources over their
allocation
- Request origins which can be represented by Head-End tunnel
ending IP address, originating AS#, neighbor AS#, neighbor ASBR
interface IP address, etc.
- DS-TE TE-Class <Class-Type, Preemption>
- FRR attribute: local protection desired bit, node protection
desired bit, and bandwidth protection desired bit carried in the
- SESSION ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path
message as defined in [TE-FRR]
- Optimization allowed or not allowed
In some cases, a TE policy server could also be used for the
enforcement of inter-AS TE policies. Implementations SHOULD allow
the use of a policy enforcement server. This requirement could allow
SPs to make the inter-AS TE policies scale better.
The signaling of a non-policy-compliant request SHOULD trigger the
generation of a RSVP Path Error message by the policy enforcing node
towards the Head-end LSR, indicating the cause. The Head-end LSR
SHOULD take appropriate actions, such as re-route, upon receipt of
such a message.
5.2.2.2. Inter-AS TE Rewrite Policies
In some situations, SPs may need to rewrite some attributes of the
incoming inter-AS TE signaling requests due to a lack of resources
for a particular TE-Class, non-compliant preemption, or mutual
agreements. The following provides a non-exhaustive list of the
parameters that can potentially be rewritten at the AS boundaries:
- RSVP-TE session attributes: affinities and preemption priorities
- DS-TE TE-Class <Class-Type, Preemption>
- ERO expansion requests
Similarly, the rewriting node SHOULD generate a RSVP Path Error
Message towards the Head-end LSR indicating the cause in terms of
types of changes made so as to maintain the end-to-end integrity of
the inter-AS TE LSP.
5.2.2.3. Inter-AS Traffic Policing
The proposed solution SHOULD also provide a set of policing
mechanisms which could be configured on the inter-AS links to ensure
that traffic routed through the tunnel does not exceed the bandwidth
negotiated during LSP signaling.
For example, an ingress policer could be configured to enforce the
traffic contract on the mutually agreed resource requirements of the
established inter-AS TE LSP (i.e., RSVP bandwidth) on the interface
to which the inter-AS link is connected.
6. Security Considerations
The proposed solution(s) MUST address security issues across multiple
SP administrative domains. Although inter-AS MPLS TE is not expected
to add specific security extensions beyond those of current intra-AS
TE, greater considerations MUST be given in terms of how to establish
a trusted model across AS boundaries. SPs SHOULD have a means to
authenticate (such as using RSVP INTEGRITY Object), to allow, and to
possibly deny inter-AS signaling requests. Also, SPs SHOULD be
protected from DoS attacks.
7. Acknowledgements
We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik
Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Ed
Kern, Jim Boyle, Thomas Nadeau, Yakov Rekhter, and Bert Wijnen for
their suggestions and helpful comments during the discussions of this
document.
8. Normative References
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M.,
and J. McManus, "Requirements for Traffic Engineering
Over MPLS", RFC 2702, September 1999.
[TE-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Informative References
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in
Progress, October 2004.
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W., and J.
Wroclawski, "Assured Forwarding PHB Group", RFC 2597,
June 1999.
[DIFF_EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[MPLS-Diff] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
X. Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, May 2002.
[PSTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[TE-APP] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche,
D., Christian, B., and W. Lai, "Applicability
Statement for Traffic Engineering with MPLS", RFC
3346, August 2002.
[GMPLS-ROUT] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[LSPPING] Kompella, K. and G. Swallow, "Detecting MPLS Data
Plane Failures", Work in Progress, May 2005.
[MPLS-TTL] Agarwal, P. and B. Akyol, "Time To Live (TTL)
Processing in Multi-Protocol Label Switching (MPLS)
Networks", RFC 3443, January 2003.
[DS-TE] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[TE-FRR] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[MPLS-LSPHIE] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC
4206, September 2005.
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi-
Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to RSVP-TE", Work in Progress,
August 2005.
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "Path
Computation Element (PCE) Architecture", Work in
Progress, September 2005.
[PCE-COM] Vasseur, J.-P., et al., "Path Computation Element
(PCE) communication Protocol (PCEP) - Version 1",
Work in Progress, September 2005.
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering
In today’s Service Provider (SP) network, BGP is deployed to meet two
different sets of requirements:
- Establishing a scalable exterior routing plane separate from the
data forwarding plane within SP’s administrative domain
- Exchanging network reachability information with different BGP
autonomous systems (ASes) that could belong to a different SP or
simply, a different AS within a SP network
Over connections across the AS boundaries, traffic engineering may
also be accomplished via a set of BGP capabilities by appropriately
enforcing BGP-based inter-AS routing policies. The current BGP-based
inter-AS traffic engineering practices may be summarized as follows:
- "Closest exit" routing where egress traffic from one SP to
another follows the path defined by the lowest IGP or intra-AS
MPLS TE tunnel metrics of the BGP next-HOP of exterior routes
learned from other ASes over the inter-AS links
- "BGP path attribute"-based routing selection mechanism where the
egress traffic path is determined by interconnect (peering or
transit) policies based upon one or a combination of BGP path
attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and Local_Pref.
SPs have often faced a number of nondeterministic factors in the
practices of inter-AS traffic engineering employing the methods
mentioned above:
- Sub-optimum traffic distribution across inter-AS links
- Nondeterministic traffic condition changes due to uncoordinated
IGP routing policies or topology changes within other AS and
uncoordinated BGP routing policy changes (MED or as-prepend,
etc.)
In addition, to achieve some degrees of granularity, SPs may choose
to enforce BGP inter-AS policies. These policies are specific to one
inter-AS link or to a set of inter-AS links for ingress traffic. By
tagging certain sets of routes with a specific attribute when
announcing to another AS, the ingress traffic is destined to certain
PoPs or to regions within SP’s network from another AS. Of course,
this operates on the assumption that the other AS permits automated
egress policy by matching the predefined attribute from incoming
routes.
Editors’ Addresses
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond_zhang@infonet.com
J.-P. Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.