idnits 2.17.1 draft-ietf-mpls-rsvp-te-hsmp-lsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 03, 2013) is 3974 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4090' is defined on line 307, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jin 3 Internet-Draft F. Jounay 4 Intended status: Informational France Telecom 5 Expires: December 05, 2013 M. Bhatia 6 Alcatel-Lucent 7 S. Kini 8 Ericsson 9 June 03, 2013 11 Hub and Spoke Multipoint Label Switched Path Tunnels 12 draft-ietf-mpls-rsvp-te-hsmp-lsp-00 14 Abstract 16 There are applications that require bi-directional, co-routed and 17 guaranteed communication from a root node to several leaf nodes in a 18 hub and spoke fashion. To meet such application requirements in a 19 Multi-protocol Label Switching (MPLS) network this draft defines a 20 Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP 21 TE LSP) with resource reservations for guaranteed communication. 22 This draft also defines a protocol to setup such LSPs by re-using and 23 extending P2MP RSVP-TE. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 05, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 61 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 62 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Time Synchronization . . . . . . . . . . . . . . . . . . 3 64 3.2. P2MP pseudowire . . . . . . . . . . . . . . . . . . . . . 3 65 4. Scalability issues . . . . . . . . . . . . . . . . . . . . . 3 66 5. Hub and Spoke Multipoint LSP . . . . . . . . . . . . . . . . 4 67 5.1. Data plane . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 9.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 There are many applications that require one-to-many bi-directional 80 communication. Some of these applications are described in Section 3 81 along with their requirements from the network. Making such 82 applications work over a MPLS network by using both P2MP and P2P 83 constructs results in scalability issues and these are discussed in 84 Section 4. This document defines a technique to do one-to-many bi- 85 directional communication over an MPLS network that re-uses the 86 existing P2MP and P2P constructs in MPLS but combines them in a 87 scalable manner. This technique re-uses and extends the current 88 traffic-engineered P2MP and P2P constructs and protocols. It is 89 described in detail in Section 5. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Abbreviations and Terminology 99 HSMP LSP - Hub and Spoke Multipoint LSP 101 3. Applications 103 We describe two representative applications that require one-to-many 104 bi-directional communication. The first is the 'Time 105 Synchronization' application described in 2.1. The second is the 106 P2MP pseudowire application and is described in section 2. 108 3.1. Time Synchronization 110 Time Synchronization [IEEE1588] over an MPLS network is being defined 111 in [I-D.ietf-tictoc-1588overmpls]. A scalable time-sync architecture 112 requires the master to provide time synchronization to a large number 113 of slaves. It requires the PTP messages to flow bi-directionally 114 between master and slave in a hub and spoke manner. More importantly 115 these messages must have the same delay in both directions. This 116 requires the underlying network to reserve resources to transport PTP 117 messages and also to co-route them in both directions to avoid any 118 differences in the delays of the paths in both directions. 120 3.2. P2MP pseudowire 122 A P2MP PW [I-D.ietf-pwe3-p2mp-pw] is required for the VPMS service 123 [I-D.ietf-l2vpn-vpms-frmwk-requirements]. In this application the 124 root PE requires bi-directional communication with several leaf PEs. 125 The underlying MPLS transport should support this type of 126 communication for the P2MP PW in a reliable and efficient manner. 128 4. Scalability issues 130 A straightforward method to achieve one-to-many bi-directional 131 communication with resource guarantees is to use a P2MP RSVP-TE 132 tunnel from the hub PE to the spoke PEs and use P2P RSVP-TE tunnels 133 from each spoke PE to the hub PE. The spoke-to-hub P2P tunnels can 134 be explicitly routed such that they are co-routed along the reverse 135 direction of the P2MP tunnel. In this model, scalability issues 136 arise both in the data plane and the control plane as explained below 137 in this section. 139 For the purpose of this discussion, an application with a hub and 140 spoke bi-directional communication over a tree topology MPLS network 141 is illustrated in Figure 1. The hub LSR is A and the spoke LSRs are 142 E, F, G, and H. For communication from the hub to the spokes, a P2MP 143 LSP can be setup with A as the root and E, F, G and H as leaves. For 144 communication from the spokes to the hub, a P2P LSP can be setup from 145 each spoke to the hub. 147 A 148 | 149 B 150 / \ 151 / \ 152 / \ 153 C D 154 / \ / \ 155 E F G H 157 Figure 1: Hub and spoke LSP over a tree topology 159 Each LSR along this tree will have to allocate a unique label for 160 each of the P2P LSPs that go from spoke to hub through it. This 161 leads to a linear increase in forwarding state at each LSR in 162 proportion to the number of spoke nodes that are in its sub-tree. 163 This has poor scaling characteristics in the data plane as the number 164 of spoke nodes increase. 166 Each LSR also has to allocate control plane state for each of the P2P 167 LSPs that go from spoke to hub through it. Each P2P LSP will need a 168 separate path state block (PSB) and a reservation state block (RSB) 169 and these will store additional information on signaling attributes. 170 This state is in addition to the state maintained for the P2MP LSP. 171 Clearly this state too increases linearly with the number of spoke 172 nodes that are in its sub-tree. This too has poor scaling 173 characteristics in the control plane as the number of spoke nodes 174 increase. Also the number of signaling messages increases linearly 175 though some of it may be mitigated by using refresh reduction 176 [RFC2961]. 178 5. Hub and Spoke Multipoint LSP 180 To solve the issues identified in Section 4 this document defines a 181 hub and spoke traffic-engineered multipoint LSP (HSMP TE LSP) with 182 resource reservations. Such an LSP is a combination of an explicitly 183 routed uni-directional traffic-engineered P2MP LSP from the hub to 184 the spokes and a co-routed uni-directional MP2P LSP from the spokes 185 to the hub. The data plane for a HSMP TE LSP is explained in 186 Section 5.1 and the control plane is explained in Section 5.2 188 5.1. Data plane 190 In the direction from hub-to-spoke the data plane processing is the 191 same as that of a P2MP LSP. In the direction from the spokes to the 192 hub, each LSR allocates labels for its upstream LSRs. Each LSR 193 merges the traffic received from multiple upstream LSRs before 194 forwarding it on the LSP towards the hub. It should be noted that 195 due to label merging the GAL processing in the direction from spoke 196 to hub is not defined. 198 5.2. Control Plane 200 The signaling protocol to setup a HSMP TE LSP can re-use the 201 signalling protocol for P2MP RSVP-TE [RFC4875] with some extensions. 202 The hub and spokes of a HSMP LSP can be modeled the same as the 203 source and leaves respectively of a P2MP LSP. A source-to-leaf (S2L) 204 sub-LSP defined in [RFC4875] for the P2MP LSP is used to represent a 205 hub-to-spoke communication of the HSMP LSP. To signal the bi- 206 directional co-routed nature of the communication from the hub to the 207 spoke, the extensions defined in section 3 of [RFC3473] must be used. 208 Each Path message of a HSMP LSP LSR MUST have a Upstream_Label 209 object. If a PathErr is received in response with a "Routing problem 210 /Unacceptable label value" indication then the Acceptable Label Set 211 (if present) must be examined to allocate a label for the 212 Upstream_Label object. If an LSR signaling an HSMP LSP receives 213 PathErr messages with different Acceptable Label Sets from different 214 neighboring LSRs then it may need to allocate more than one label to 215 satisfy all the Acceptable Label Sets. The LSR should try to 216 minimize the number of unique labels allocated for a HSMP LSP in such 217 a case. 219 Pruning and grafting for a HSMP LSP follow the same procedures as for 220 a P2MP LSP. During re-merge in addition to the procedures in section 221 18.1.1 of [RFC4875] the ingress or transit LSR that creates the 222 branch would also be a re-merge LSR for the traffic from the spokes 223 towards the hub. Also the re-merge node for the traffic from hub to 224 spoke would be a branching node for traffic from the spokes to the 225 hub. The LSR that is branching the traffic from the spokes to the 226 hub would duplicate the traffic whereas the LSR that is re-merging 227 the traffic should forward traffic only from one the incoming 228 interfaces. 230 The HSMP LSP also requires bandwidth allocation that is asymmetric 231 between the hub-to-spoke and the spoke-to-hub direction. At the same 232 time it requires the spokes to be able to request different amounts 233 of bandwidth towards the hub. The protocol extensions defined in 234 [RFC6387] are used for asymmetric bandwidth allocation between the 235 hub-to-spoke and spoke-to-hub directions. The UPSTREAM_TSPEC, 236 UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC objects are also used in a HSMP 237 LSP. However in case of a HSMP LSP an intermediate LSR can receive 238 different UPSTREAM_TSPECs in the Resv messages from neighboring LSRs. 239 Combining these Tspecs and generating an appropriate 240 UPSTREAM_FLOWSPEC towards each spoke is still under discussion. 241 Also, processing a received UPSTREAM_FLOWSPEC and generating 242 appropriate UPSTREAM FLOWSPECs in the hub to spoke direction is also 243 under discussion. 245 6. Acknowledgements 247 We would like to thank Dimitri Papadimitriou, Yuji Kamite, Sebastien 248 Jobert for their comments and feedback on the document. 250 7. IANA Considerations 252 This memo includes no request to IANA. 254 8. Security Considerations 256 The same security considerations apply as for the RSVP-TE P2MP LSP 257 [RFC4875] specification. 259 9. References 261 9.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 267 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 268 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 270 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 271 "Extensions to Resource Reservation Protocol - Traffic 272 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 273 Switched Paths (LSPs)", RFC 4875, May 2007. 275 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 276 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 277 Switched Paths (LSPs)", RFC 6387, September 2011. 279 9.2. Informative References 281 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 282 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 283 and L. Jin, "Framework and Requirements for Virtual 284 Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- 285 frmwk-requirements-05 (work in progress), October 2012. 287 [I-D.ietf-pwe3-p2mp-pw] 288 Sivabalan, S., Boutros, S., and L. Martini, "Signaling 289 Root-Initiated Point-to-Multipoint Pseudowire using LDP", 290 draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. 292 [I-D.ietf-tictoc-1588overmpls] 293 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 294 Montini, "Transporting Timing messages over MPLS 295 Networks", draft-ietf-tictoc-1588overmpls-04 (work in 296 progress), February 2013. 298 [IEEE1588] 299 IEEE 1588-2008, "IEEE Standard for a Precision Clock 300 Synchronization Protocol for Networked Measurement and 301 Control Systems ", 2008. 303 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 304 and S. Molendini, "RSVP Refresh Overhead Reduction 305 Extensions", RFC 2961, April 2001. 307 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 308 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 309 2005. 311 Authors' Addresses 313 Lizhong Jin 315 Email: lizho.jin@gmail.com 317 Frederic Jounay 318 France Telecom 320 Email: frederic.Jounay@orange.ch 321 Manav Bhatia 322 Alcatel-Lucent 324 Email: manav.bhatia@alcatel-lucent.com 326 Sriganesh Kini 327 Ericsson 329 Email: sriganesh.kini@ericsson.com