One document matched: draft-li-mpls-proxy-te-lsp-00.txt
Network Working Group Z. Li
Internet-Draft X. Zeng
Intended status: Standards Track Huawei Technologies
Expires: January 09, 2014 July 08, 2013
Proxy MPLS Traffic Engineering Label Switched Path(LSP)
draft-li-mpls-proxy-te-lsp-00
Abstract
This document describes a method to setup MPLS TE proxy egress LSP
which helps setup end-to-end LSP through stitching MPLS TE proxy
egress LSP with BGP LSP in the Seamless MPLS network. The method is
achieved by new Proxy Destination Object carried in RSVP-TE messages.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 09, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Li & Zeng Expires January 09, 2014 [Page 1]
Internet-Draft Proxy TE LSP July 2013
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proxy Destination Object . . . . . . . . . . . . . . . . . . 4
4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Seamless MPLS[I-D.ietf-mpls-seamless-mpls] provides an end to end
service independent transport architecture. It removes the need for
service specific configurations in network transport nodes. Seamless
MPLS uses existing protocols like LDP, IS-IS to build intra-area
segments and uses MP-BGP as the inter-area routing and label
distribution protocol.
One common procedure of setting up the end-to-end transport LSP is as
follows:
1. Setup the access segment LSP from Access Node (AN) to Aggregation
Node (AGN) using LDP with longest-match as defined in [RFC5283]. It
requires only static routes and it is not necessary to know the
actual destination (FEC of the LDP LSP);
2. The Aggregation Node (AGN) stitches the egress LDP LSP with the
BGP ingress LSP according to the key of FEC;
3. The remote Aggregation Node (AGN) stitches the egress BGP LSP
with an ingress LSP according to the key of FEC.
LSPs set up with MPLS TE (RSVP-TE) provide a higher reliability and
better QoS as compared to LSPs set up with LDP. So MPLS TE is always
adopted to deploy in the mobile backhaul network. But when the
mobile backhaul network integrates with the core/aggregation network
based on Seamless MPLS, it is difficult to setup end-to-end MPLS TE
Li & Zeng Expires January 09, 2014 [Page 2]
Internet-Draft Proxy TE LSP July 2013
LSP spanning multiple domains. The possible way to setup the end-to-
end LSP is that the proxy egress RSVP-TE LSP should be able to setup
in the mobile backhaul network to stitch with BGP LSP at the
Aggregation Node.
This document extends RSVP-TE extension and introduces a new Proxy
Destination Object. Through the RSVP-TE extension the proxy egress
LSP can setup for RSVP-TE. It makes possible to setup the end-to-end
LSP when deploy MPLS TE in the Seamless MPLS scenario to integrate
the mobile backhaul network with the core/aggregation network.
2. Terminology
Proxy Egress LSP: It is defined in Sec. 4.1.4 of [RFC3031]. It is
the LSP which is setup by the proxy egress LSR instead of the actual
destination LSR.
3. Solutions
When setup a proxy egress RSVP-TE LSP in the Seamless MPLS scenario
as shown in the Figure 1, there are two destination addresses to be
carried by the RSVP-TE message: the actual destination address is the
destination address of the end-to-end LSP by stitching the proxy
egress LSP and the BGP LSP, the proxy destination address is the
address of Aggregation Node which stitches the proxy egress RSVP-TE
LSP and BGP LSP. When setting up the proxy egress RSVP-TE LSP on the
Access Node, it is necessary to specify the actual destination
address and the proxy destination address. The access node needs to
calculate the path based on the proxy destination address for the
proxy egress RSVP-TE LSP. The Path message will be sent from the
ingress node to the proxy destination node which is identified by the
proxy destination address in the message. Then the proxy destination
node sends back the Resv message to allocate label and reserve
resource. The actual destination address is used to stitch with BGP
LSP which has the same address as the actual destination address of
the proxy egress RSVP-TE LSP.
| IGP X | | IGPY |
|(Access/Aggregation)| (Core) |Access/Aggregation)|
|--------------------|--------------|-------------------|
| | | |
+-----+ +-----+
...|AGN |.......|AGN |....
+----+ ........ +-----+ +-----+ ....... +----+
| AN |... ...| AN |
+----+ ..... ..... +----+
..... +-----+ +-----+ .....
Li & Zeng Expires January 09, 2014 [Page 3]
Internet-Draft Proxy TE LSP July 2013
..|AGN |.......|AGN |..
+-----+ +-----+
| | Hierarchical | |
| | BGP LSP | |
| +--------------------+ |
| MPLS TE LSP | | MPLS TE LSP |
+-----------------+ +---------------+
| |--------------------| |
| | MPLS LDP | |
Figure 4 Seamless MPLS Scenario with MPLS TE
In order to support setup of the proxy egress RSVP-TE LSP, the new
Proxy Destination Object is introduced to carry the proxy destination
address besides that the actual destination address is carried in the
Session Object. Both the Session Object and the Proxy Destination
Object are carried in the RSVP-TE Path message and Resv message to
set up the proxy egress LSP.
4. Proxy Destination Object
4.1. Format
The Proxy Destination Object is an optional object which may be
carried in Path or Resv Messages. The Proxy Destination Class-Number
is TBD (of form 0bbbbbbb). RSVP-TE routers that do not support the
object SHOULD reject the entire message and return an "Unknown Object
Class" error.
The format of the Proxy Destination Object is as follows:
1. IPv4 Proxy Destination Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Proxy Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Proxy Destination Address: 32 bits. IPv4 address of the proxy
destination address of the proxy egress RSVP-TE LSP.
2. IPv6 Proxy Destination Object
Li & Zeng Expires January 09, 2014 [Page 4]
Internet-Draft Proxy TE LSP July 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Proxy Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Proxy Destination Address: 16 bytes. IPv6 address of the proxy
destination address of the proxy egress RSVP-TE LSP.
If a message contains multiple Proxy Destination Objects, only the
first object is meaningful. Subsequent Proxy Destination Objects
SHOULD be ignored and SHOULD NOT be propagated.
4.2. Procedures
When the ingress node sets up the proxy egress LSP, the Proxy
Destination Object MUST be inserted in the Path message to indicate
the address of the proxy destination node that would stitch the proxy
egress LSP with other LSPs. When receive the RESV messages, the
ingress node SHOULD check if the Proxy Destination is included. If
the Path message include the Proxy Destination object and the
corresponding RESV message does not include this object, the ingress
node MUST treat the Resv message as wrong messages and MUST NOT set
up LSP.
On the transit node, when receiving the messages with Proxy
Destination object, it MUST include the Proxy Destination object in
the outgoing Path or Resv message without change of the object. When
it is necessary for the transit node to calculate the path, the proxy
destination address identified by the Object MUST be used instead of
the actual destination address identified by the Session Object. If
the transit node receives the Path message including the Proxy
Destination object but receives the corresponding Resv message which
does not include this object, it MUST treat the Resv message as wrong
message can MUST NOT set up LSP.
On the egress node, when receiving Path messages with Proxy
Destination object, it MUST include this object in the corresponding
Resv message.
5. IANA Considerations
TBD.
Li & Zeng Expires January 09, 2014 [Page 5]
Internet-Draft Proxy TE LSP July 2013
6. Security Considerations
This document does not introduce any additional security issues above
those identified in [RFC3209].
7. Acknowledgements
The authors would like to thank Loa Andersson for his valuable
comments and suggestions on this draft.
8. Normative References
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-03 (work in progress), May 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] 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.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li & Zeng Expires January 09, 2014 [Page 6]
Internet-Draft Proxy TE LSP July 2013
Xinzong Zeng
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zengxinzong@huawei.com
Li & Zeng Expires January 09, 2014 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-21 19:10:29 |