Internet DRAFT - draft-jjb-mpls-rsvp-te-hsmp-lsp
draft-jjb-mpls-rsvp-te-hsmp-lsp
Network Working Group L. Jin
Internet-Draft F. Jounay
Intended status: Informational France Telecom
Expires: November 14, 2013 M. Bhatia
Alcatel-Lucent
S. Kini
Ericsson
May 13, 2013
Hub and Spoke Multipoint Label Switched Path Tunnels
draft-jjb-mpls-rsvp-te-hsmp-lsp-04
Abstract
There are applications that require bi-directional, co-routed and
guaranteed communication from a root node to several leaf nodes in a
hub and spoke fashion. To meet such application requirements in a
Multi-protocol Label Switching (MPLS) network this draft defines a
Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP
TE LSP) with resource reservations for guaranteed communication.
This draft also defines a protocol to setup such LSPs by re-using and
extending P2MP RSVP-TE.
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 November 14, 2013.
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
Jin, et al. Expires November 14, 2013 [Page 1]
Internet-Draft HSMP LSP Tunnels May 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Time Synchronization . . . . . . . . . . . . . . . . . . 3
3.2. P2MP pseudowire . . . . . . . . . . . . . . . . . . . . . 3
4. Scalability issues . . . . . . . . . . . . . . . . . . . . . 3
5. Hub and Spoke Multipoint LSP . . . . . . . . . . . . . . . . 4
5.1. Data plane . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
There are many applications that require one-to-many bi-directional
communication. Some of these applications are described in Section 3
along with their requirements from the network. Making such
applications work over a MPLS network by using both P2MP and P2P
constructs results in scalability issues and these are discussed in
Section 4. This document defines a technique to do one-to-many bi-
directional communication over an MPLS network that re-uses the
existing P2MP and P2P constructs in MPLS but combines them in a
scalable manner. This technique re-uses and extends the current
traffic-engineered P2MP and P2P constructs and protocols. It is
described in detail in Section 5.
1.1. 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].
Jin, et al. Expires November 14, 2013 [Page 2]
Internet-Draft HSMP LSP Tunnels May 2013
2. Abbreviations and Terminology
HSMP LSP - Hub and Spoke Multipoint LSP
3. Applications
We describe two representative applications that require one-to-many
bi-directional communication. The first is the 'Time
Synchronization' application described in 2.1. The second is the
P2MP pseudowire application and is described in section 2.
3.1. Time Synchronization
Time Synchronization [IEEE1588] over an MPLS network is being defined
in [I-D.ietf-tictoc-1588overmpls]. A scalable time-sync architecture
requires the master to provide time synchronization to a large number
of slaves. It requires the PTP messages to flow bi-directionally
between master and slave in a hub and spoke manner. More importantly
these messages must have the same delay in both directions. This
requires the underlying network to reserve resources to transport PTP
messages and also to co-route them in both directions to avoid any
differences in the delays of the paths in both directions.
3.2. P2MP pseudowire
A P2MP PW [I-D.ietf-pwe3-p2mp-pw] is required for the VPMS service
[I-D.ietf-l2vpn-vpms-frmwk-requirements]. In this application the
root PE requires bi-directional communication with several leaf PEs.
The underlying MPLS transport should support this type of
communication for the P2MP PW in a reliable and efficient manner.
4. Scalability issues
A straightforward method to achieve one-to-many bi-directional
communication with resource guarantees is to use a P2MP RSVP-TE
tunnel from the hub PE to the spoke PEs and use P2P RSVP-TE tunnels
from each spoke PE to the hub PE. The spoke-to-hub P2P tunnels can
be explicitly routed such that they are co-routed along the reverse
direction of the P2MP tunnel. In this model, scalability issues
arise both in the data plane and the control plane as explained below
in this section.
Jin, et al. Expires November 14, 2013 [Page 3]
Internet-Draft HSMP LSP Tunnels May 2013
For the purpose of this discussion, an application with a hub and
spoke bi-directional communication over a tree topology MPLS network
is illustrated in Figure 1. The hub LSR is A and the spoke LSRs are
E, F, G, and H. For communication from the hub to the spokes, a P2MP
LSP can be setup with A as the root and E, F, G and H as leaves. For
communication from the spokes to the hub, a P2P LSP can be setup from
each spoke to the hub.
A
|
B
/ \
/ \
/ \
C D
/ \ / \
E F G H
Figure 1: Hub and spoke LSP over a tree topology
Each LSR along this tree will have to allocate a unique label for
each of the P2P LSPs that go from spoke to hub through it. This
leads to a linear increase in forwarding state at each LSR in
proportion to the number of spoke nodes that are in its sub-tree.
This has poor scaling characteristics in the data plane as the number
of spoke nodes increase.
Each LSR also has to allocate control plane state for each of the P2P
LSPs that go from spoke to hub through it. Each P2P LSP will need a
separate path state block (PSB) and a reservation state block (RSB)
and these will store additional information on signaling attributes.
This state is in addition to the state maintained for the P2MP LSP.
Clearly this state too increases linearly with the number of spoke
nodes that are in its sub-tree. This too has poor scaling
characteristics in the control plane as the number of spoke nodes
increase. Also the number of signaling messages increases linearly
though some of it may be mitigated by using refresh reduction
[RFC2961].
5. Hub and Spoke Multipoint LSP
To solve the issues identified in Section 4 this document defines a
hub and spoke traffic-engineered multipoint LSP (HSMP TE LSP) with
resource reservations. Such an LSP is a combination of an explicitly
routed uni-directional traffic-engineered P2MP LSP from the hub to
the spokes and a co-routed uni-directional MP2P LSP from the spokes
to the hub. The data plane for a HSMP TE LSP is explained in
Section 5.1 and the control plane is explained in Section 5.2
Jin, et al. Expires November 14, 2013 [Page 4]
Internet-Draft HSMP LSP Tunnels May 2013
5.1. Data plane
In the direction from hub-to-spoke the data plane processing is the
same as that of a P2MP LSP. In the direction from the spokes to the
hub, each LSR allocates labels for its upstream LSRs. Each LSR
merges the traffic received from multiple upstream LSRs before
forwarding it on the LSP towards the hub. It should be noted that
due to label merging the GAL processing in the direction from spoke
to hub is not defined.
5.2. Control Plane
The signaling protocol to setup a HSMP TE LSP can re-use the
signalling protocol for P2MP RSVP-TE [RFC4875] with some extensions.
The hub and spokes of a HSMP LSP can be modeled the same as the
source and leaves respectively of a P2MP LSP. A source-to-leaf (S2L)
sub-LSP defined in [RFC4875] for the P2MP LSP is used to represent a
hub-to-spoke communication of the HSMP LSP. To signal the bi-
directional co-routed nature of the communication from the hub to the
spoke, the extensions defined in section 3 of [RFC3473] must be used.
Each Path message of a HSMP LSP LSR MUST have a Upstream_Label
object. If a PathErr is received in response with a "Routing problem
/Unacceptable label value" indication then the Acceptable Label Set
(if present) must be examined to allocate a label for the
Upstream_Label object. If an LSR signaling an HSMP LSP receives
PathErr messages with different Acceptable Label Sets from different
neighboring LSRs then it may need to allocate more than one label to
satisfy all the Acceptable Label Sets. The LSR should try to
minimize the number of unique labels allocated for a HSMP LSP in such
a case.
Pruning and grafting for a HSMP LSP follow the same procedures as for
a P2MP LSP. During re-merge in addition to the procedures in section
18.1.1 of [RFC4875] the ingress or transit LSR that creates the
branch would also be a re-merge LSR for the traffic from the spokes
towards the hub. Also the re-merge node for the traffic from hub to
spoke would be a branching node for traffic from the spokes to the
hub. The LSR that is branching the traffic from the spokes to the
hub would duplicate the traffic whereas the LSR that is re-merging
the traffic should forward traffic only from one the incoming
interfaces.
The HSMP LSP also requires bandwidth allocation that is asymmetric
between the hub-to-spoke and the spoke-to-hub direction. At the same
time it requires the spokes to be able to request different amounts
of bandwidth towards the hub. The protocol extensions defined in
[RFC6387] are used for asymmetric bandwidth allocation between the
hub-to-spoke and spoke-to-hub directions. The UPSTREAM_TSPEC,
Jin, et al. Expires November 14, 2013 [Page 5]
Internet-Draft HSMP LSP Tunnels May 2013
UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC objects are also used in a HSMP
LSP. However in case of a HSMP LSP an intermediate LSR can receive
different UPSTREAM_TSPECs in the Resv messages from neighboring LSRs.
Combining these Tspecs and generating an appropriate
UPSTREAM_FLOWSPEC towards each spoke is still under discussion.
Also, processing a received UPSTREAM_FLOWSPEC and generating
appropriate UPSTREAM FLOWSPECs in the hub to spoke direction is also
under discussion.
6. Acknowledgements
We would like to thank Dimitri Papadimitriou, Yuji Kamite, Sebastien
Jobert for their comments and feedback on the document.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
The same security considerations apply as for the RSVP-TE P2MP LSP
[RFC4875] specification.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 2011.
Jin, et al. Expires November 14, 2013 [Page 6]
Internet-Draft HSMP LSP Tunnels May 2013
9.2. Informative References
[I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
frmwk-requirements-05 (work in progress), October 2012.
[I-D.ietf-pwe3-p2mp-pw]
Sivabalan, S., Boutros, S., and L. Martini, "Signaling
Root-Initiated Point-to-Multipoint Pseudowire using LDP",
draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
[I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-04 (work in
progress), February 2013.
[IEEE1588]
IEEE 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems ", 2008.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
Authors' Addresses
Lizhong Jin
Email: lizho.jin@gmail.com
Frederic Jounay
France Telecom
Email: frederic.Jounay@orange.ch
Jin, et al. Expires November 14, 2013 [Page 7]
Internet-Draft HSMP LSP Tunnels May 2013
Manav Bhatia
Alcatel-Lucent
Email: manav.bhatia@alcatel-lucent.com
Sriganesh Kini
Ericsson
Email: sriganesh.kini@ericsson.com
Jin, et al. Expires November 14, 2013 [Page 8]
