idnits 2.17.1 draft-shen-spring-p2mp-transport-chain-04.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 14, 2021) is 1040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 244 -- Looks like a reference, but probably isn't: '2' on line 246 -- Looks like a reference, but probably isn't: '3' on line 442 == Missing Reference: 'XL' is mentioned on line 306, but not defined == Missing Reference: 'EoC' is mentioned on line 306, but not defined == Unused Reference: 'RFC7274' is defined on line 515, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin Shen 3 Internet-Draft Zhaohui Zhang 4 Intended status: Standards Track Juniper Networks 5 Expires: December 16, 2021 Rishabh Parekh 6 Cisco Systems 7 Hooman Bidgoli 8 Nokia 9 Yuji Kamite 10 NTT Communications 11 June 14, 2021 13 Point-to-Multipoint Transport Using Chain Replication in Segment Routing 14 draft-shen-spring-p2mp-transport-chain-04 16 Abstract 18 This document specifies a point-to-multipoint (P2MP) transport 19 mechanism based on chain replication. It can be used in segment 20 routing to achieve traffic optimization for multicast. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 16, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. P2MP Transport Using Chain Replication . . . . . . . . . . . 4 60 4.1. P2MP Chain . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Bud Segment . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Forwarding Behaviors . . . . . . . . . . . . . . . . . . 6 63 4.3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Path Computation for P2MP Chains . . . . . . . . . . . . . . 9 67 6. Special Purpose Bud Segments . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 11.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The Segment Routing Architecture [RFC8402] describes segment routing 80 (SR) and its instantiation in two data planes, i.e. MPLS and IPv6. 81 In SR, point-to-multipoint (P2MP) transport is currently achieved by 82 using two approaches. The first approach is ingress replication, 83 where a dedicated point-to-point (P2P) SR tunnel is set up from a 84 root node to each leaf node, and the root node replicates and sends 85 packets via a bundle of such P2P SR tunnels to all the leaf nodes. 86 Although this approach provides P2MP reachability, it does not 87 consider traffic optimization across the tunnels. 89 The second approach is to use P2MP trees. This approach can achieve 90 maximum traffic optimization, but it relies a controller or path 91 computation element (PCE) to provision and manage "replication 92 segments" on branch nodes. The replication segments are essentially 93 P2MP-tree state (i.e. transport tunnel state) on transit routers. 94 Therefore, this approach is not fully aligned with SR's principles of 95 single-point provisioning (at ingress routers) and stateless core 96 network. 98 This document introduces a new solution for P2MP transport in SR, 99 based on "chain replication". In this solution, P2MP transport is 100 achieved by constructing a set of "P2MP chain tunnels" (or simply 101 "P2MP chains") from a root node to leaf nodes. Each P2MP chain is a 102 single-path tunnel, with a leaf node at tail end and some transit 103 leaf nodes along the path, resembling a chain. The leaf node at the 104 tail end behaves as a normal receiver. Each transit leaf node 105 behaves as a receiver and a transit router, by replicating incoming 106 packets once for local processing off the chain, and forwarding the 107 original packets down the chain. The root node sends packets via the 108 set of P2MP chains to all the leaf nodes. 110 As each P2MP chain can reach multiple leaf nodes via a single flow of 111 packets, this solution is considered to be more optimal than ingress 112 replication. Compared to the P2MP-tree based approach, this solution 113 can retain the simplicity of SR, including single-point provisioning 114 and statelessness in the core of a network. 116 2. Specification of Requirements 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] and 121 [RFC8174]. 123 3. Applicability 125 The P2MP transport mechanism in this document is generally applicable 126 to all networks. However, it may benefit more for certain types of 127 topologies than others. These topologies include ring topologies, 128 linear topologies, topologies with leaf nodes concentrated in 129 geographical sites which can be modeled as leaf groups (or clusters), 130 etc. 132 The mechanism does not create any state of P2MP tunnel or P2MP tree 133 on routers. It is transparent to all transit routers. Leaf nodes 134 intended to take advantage of the mechanism will need to support the 135 new forwarding behaviors specified in this document. For other leaf 136 nodes, the mechanism has a backward compatibility to allow them to be 137 reached by P2P tunnels of ingress replication. Path computation and 138 P2MP chain construction will need to be supported by controllers or 139 root nodes, depending on the location of the computation. 141 The mechanism is applicable to both SR-MPLS [RFC8660] and SRv6 142 [SRv6-SRH], [SRv6-Programming]. 144 In this mechanism, if a leaf node needs to know the service level 145 context (e.g. source, VPN) of a P2MP stream, it must rely on the 146 information contained in payload headers (i.e. inner headers) of 147 packets. In SR-MPLS, service labels may be allocated from a domain- 148 wide common block (DCB) to serve as globally unique context 149 indicators. In SRv6, a root node's IP address or an upstream- 150 assigned context indicator may be encoded in the source address of 151 IPv6 header, or a downstream-assigned context indicator may be 152 encoded in the ARG portion of a service SID. 154 This document introduces a new type of segments, called bud segments 155 (Section 4.2). The segments are generic in nature. They may be used 156 in cases other than P2MP transport, such as traffic mirroring and 157 monitoring, OAM, etc. These use cases are out of the scope of this 158 document. 160 4. P2MP Transport Using Chain Replication 162 In this document, a P2MP stream associated with a root node and a set 163 of leaf nodes is denoted as {root node, leaf nodes}. It is achieved 164 by using a bundle of P2MP chains covering all the leaf nodes. Each 165 P2MP chain is a single-path tunnel starting from the root node and 166 reaching one or multiple leaf nodes along the path. The tail-end 167 node of the P2MP chain is a leaf node, called a "tail-end" leaf node. 168 Each leaf node traversed by the P2MP chain is called a "transit" leaf 169 node. As a special case, a P2MP chain may have only a tail-end leaf 170 node and no transit leaf node, essentially becoming a P2P tunnel, but 171 it is not the focus of this document. 173 R ------ R1 ------ R2 ------ L1 ------ R3 ------ L2 ------ L3 175 R : root node 176 Li : leaf node 177 Ri : transit router 179 Figure 1 181 A tail-end leaf node and a transit leaf nodes have different 182 behaviors when processing an incoming packet. In particular, a tail- 183 end leaf node processes the packet as a normal receiver. A transit 184 leaf node not only processes the packet as a receiver, but also 185 forwards it downstream along the P2MP chain, hence acting as a "bud 186 node". To achieve this, the transit leaf node needs to replicate the 187 packet, producing two packets, one for forwarding and the other for 188 local processing. Such packet replication happens on every transit 189 leaf node along a P2MP chain. Therefore, it is called "chain 190 replication". 192 This document introduces a new type of segments, called "bud 193 segments", to model the above packet replication and processing on 194 transit leaf nodes. The segment ID (SID) of a bud segment is a "bud- 195 SID". 197 4.1. P2MP Chain 199 Construction of P2MP chains for a P2MP stream is performed by a 200 controller or the root node based on configuration or path 201 computation (Section 5). This generates the set of P2MP chains to 202 use, and decides the set of leaf nodes that each P2MP chain reaches. 203 In general, if not all leaf nodes can be covered by using a single 204 P2MP chain, multiple P2MP chains MUST be used, and the root node MUST 205 replicate ingress packets over the P2MP chains. 207 The path of a P2MP chain is a single path traversing one or multiple 208 transit leaf nodes and terminating at a tail-end leaf node. Between 209 the root node and the first transit leaf node, and between two 210 consecutive leaf nodes, there may be none, one, or multiple transit 211 routers. 213 The path is then translated to a SID list to be programmed on the 214 root node. In the SID list, each transit leaf node has its bud-SID 215 in a corresponding position. Given a P2MP chain to a set of leaf 216 nodes in the order of L1, L2, ..., Ln, the SID list may be 217 represented as below: 219 , L1's bud-SID, ..., , Li's 220 bud-SID, ..., 222 Where: 224 o is the sub-path from the root node to L1. 226 o is the sub-path from Li-1 to Li. 228 o is the sub-path from Ln-1 to Ln. There is 229 no need for Ln's bud-SID to be at the end of the SID list, because 230 the tail-end leaf node does not perform a chain replication. 232 Each of the above sub-paths is a regular point-to-point path, and its 233 SIDs are regular SIDs, such as adjacency-SIDs, node-SIDs, binding- 234 SIDs, etc. As a special case, a sub-path from Li-1 to Li may have an 235 empty SID list, if the sub-path takes the shortest path represented 236 by Li's bud-SID. 238 4.2. Bud Segment 240 On a transit leaf node, a bud segment represents the forwarding 241 instructions below. They are applied to an incoming packet P when 242 the packet's active SID is the bud-SID of this bud segment. 244 [1] Replicate the packet P to generate a copy P1. 246 [2] For P, perform a NEXT operation on the bud-SID, make the next 247 SID active, and forward the packet based on that SID. 249 [3] For P1, perform a sequence of NEXT operations on the bud-SID 250 and all the subsequent SIDs of the P2MP chain, and process the 251 packet locally as an endpoint. 253 Bud segments are global segments of leaf nodes. They are routable 254 segments via the shortest topological paths. Bud-SIDs are allocated 255 from SRGB (SR global block). Only one bud segment is needed per leaf 256 node, and per SR-MPLS or SRv6 dataplane. It is used only when the 257 leaf node is a transit leaf node on a P2MP chain. 259 Bud segments are shared by all P2MP streams, i.e. all instances of 260 {root node, leaf nodes}. A leaf node SHOULD advertise a bud segment 261 for SR-MPLS if its forwarding hardware supports the SR-MPLS behavior 262 (Section 4.3.1), and a bud segment for SRv6 if its forwarding 263 hardware supports the above SRv6 behavior (Section 4.3.2). The 264 advertisement may be via a protocol, e.g. ISIS, OSPF, or BGP. The 265 advertisement allows the leaf node to be considered as a transit leaf 266 node on a P2MP chain. If a leaf node does not advertise a bud 267 segment, it can only be considered as a tail-end leaf node on a P2MP 268 chain, or reached via a P2P tunnel using ingress replication. The 269 extensions of the protocols are out of the scope of this document. 271 4.3. Forwarding Behaviors 273 4.3.1. SR-MPLS 275 In SR-MPLS, bud-SIDs are labels. A root node applies a stack of 276 labels corresponding to a P2MP chain's SID list to ingress packets. 277 These labels are called P2MP chain labels. A packet may have an 278 inner service label(s), e.g. a VPN label, a bridge domain label, a 279 source Ethernet segment label, etc. In this case, the root node must 280 have a way to mark the end of P2MP chain labels in the MPLS header, 281 in order for transit leaf nodes to process the packet as receivers. 282 This document introduces an "end-of-chain" (EoC) label to facilitate 283 this. The EoC label is an extended special-purpose label (ESPL) [RFC 284 7274] with value TDB. If an ingress packet has a service label(s), 285 the root node MUST push the service label(s) first, then the 286 Extension Label (XL, value 15) and the EoC label, and finally the 287 P2MP chain labels. Hence, the [XL, EoC] labels serve as a unique 288 pattern to indicate the end of the P2MP chain labels. If a packet 289 does not have a service label(s), the root node MUST NOT push the 290 [XL, EoC] labels, but only the P2MP chain labels. 292 A transit leaf node will receive the packet (P) with the node's bud- 293 SID label as top label. The node replicates P to generate a copy P1. 294 For P, the node pops the bud-SID label and forwards the packet based 295 on the next label in the MPLS header. For P1, the node removes all 296 the P2MP chain labels, by popping labels until [XL, EoC] are popped 297 or all labels are popped. The node then processes P1 locally as an 298 SR-MPLS endpoint. 300 The tail-end leaf node will receives the packet with (1) no label; 301 (2) the [XL, EoC] labels as top labels; or (3) the node's node-SID 302 label as top label, followed by the [XL, EoC] labels. In case (3), 303 the [XL, EoC] labels will be exposed to the top after the node-SID 304 label is popped. In both cases (2) and (3), the node pops [XL, EoC] 305 and continues to process the inner service label(s). This imposes a 306 requirement on the node to be able to handle the [XL, EoC] labels as 307 described. Ultimately, the node processes the packet with no label 308 or an exposed service label(s), as an SR-MPLS endpoint. 310 4.3.2. SRv6 312 In SRv6, bud-SIDs are IPv6 addresses specifically assigned to bud 313 segments. A root node constructs a packet with an IPv6 header 314 corresponding to the P2MP chain, followed by a segment routing header 315 (SRH) containing the SIDs of the P2MP chain, and followed by an inner 316 IP header or service header. 318 A transit leaf node will receive the packet (P) with the node's bud- 319 SID as active SID. The node replicates P to generate a copy P1. For 320 P, the node performs NEXT operation on the bud-SID by adjusting the 321 IPv6 header and SRH, and forwards the packet based on the new active 322 SID. For P1, the node removes the IPv6 header and SRH, and processes 323 the packet (with the inner header exposed) as an SRv6 endpoint. 325 The tail-end leaf node will receives the packet with the IPv6 header 326 and optionally the SRH. The node processes the packet as an SRv6 327 endpoint. 329 4.4. Example 331 In the following example, P2MP transport is needed from the root node 332 R, to leaf nodes L1, L2, L3 and L4. 334 R ------ R1 -------------------- R2 ------- L1 335 | | / 336 | | / 337 | | / 338 R3 -------------------- R4 ------- L2 339 | | 340 | | 341 | | 342 R5 -------------------- R6 ------- L3 343 | | / 344 | | / 345 | | / 346 R7 -------------------- R8 ------- L4 348 Figure 2 350 Path computation results in two P2MP chains: 352 P2MP chain 1: 354 Path: R -> R1 -> R2 -> L1 -> R4 -> L2, where L1 is a transit 355 leaf node, and L2 is the tail-end leaf node. 357 Assuming that the sub-path R -> R1 -> R2 -> L1 is not the 358 shortest path from R to L1, so that an explicit sub-path must 359 be used. Also assuming that the sub-path L1 -> R4 -> L2 is the 360 shortest path from L1 to L2, so that the node-SID of L2 can be 361 used to represent this sub-path. The segment list applied to 362 packets on R is: 364 adj-SID 100 - link from R to R1 366 adj-SID 200 - link from R1 to R2 368 adj-SID 300 - link from R2 to L1 370 bud-SID 1000 - L1 372 node-SID 2000 - L2 374 P2MP chain 2: 376 Path: R -> R1 -> R3 -> R5 -> R6 -> L3 -> R8 -> L4, where L3 is 377 a transit leaf node, and L4 is the tail-end leaf node. 379 Assuming that the sub-path R -> R1 -> R3 -> R5 -> R6 -> L3 is 380 the shortest path from R to L3, so that the bud-SID of L3 can 381 be used to represent this sub-path. Also assuming that the 382 sub-path L3 -> R8 -> L4 is not the shortest path from L3 to L4, 383 so that an explicit sub-path must be used. The segment list 384 applied to packets on R is: 386 bud-SID 3000 - L3 388 adj-SID 600 - link from L3 to R8 390 adj-SID 700 - link from R8 to L4 392 node-SID 4000 - L4 394 5. Path Computation for P2MP Chains 396 P2MP chain path computation for a P2MP stream {root node, leaf nodes} 397 may be performed by a controller or the root node. Each P2MP chain 398 is a single-path tunnel. In general, any P2P path computation 399 algorithm may be extended to serve the purpose. This document does 400 not enforce a particular algorithm. 402 The path computation may consider topological metrics for shortest 403 paths, or traffic engineering (TE) constraints for TE paths. In 404 addition, this document also suggests the following constraints: 406 - Maximum hops per P2MP chain. This SHOULD be based on the 407 maximum delay allowed for packets to accumulate before reaching a 408 tail-end leaf node. 410 - Maximum length of SID list. This SHOULD be based on the maximum 411 header size which may be applied to packets by a root node. This 412 is typically a limit of forwarding hardware. Note that a SID list 413 is translated from a computed path. Hence, the SID list's length 414 and the path's hop count are not necessarily the same. 416 - Maximum leaf nodes per P2MP chain. This may be used to restrict 417 the length of each P2MP chain. 419 - Maximum hops between two consecutive leaf nodes. This may be 420 useful to avoid a sparse chain, where an excessive distance 421 between two consecutive leaf nodes will cause a P2MP chain's 422 efficiency to degrade. 424 - Maximum number of times that a node or link may be traversed by 425 a P2MP chain. This may be useful to prevent a node or link from 426 being congested by duplicate traffic. 428 The path computation tends to be deterministic in a ring or linear 429 topology. In an arbitrary topology, the path computation can be made 430 controllable by dividing leaf nodes into groups (or clusters) based 431 on geographic locations or policies, and computing a separate path 432 for each group. A leaf group may be defined as a sequence (i.e. 433 ordered) or set (i.e. unordered) of leaf nodes, which are treated as 434 loose hops in path computation. 436 6. Special Purpose Bud Segments 438 So far, the discussion has been focusing on nodal bud segments, which 439 are per node and per SR-MPLS/SRv6. The local processing represented 440 by these bud segments is completely based on a packet's inner header, 441 i.e. after all the SIDs of a P2MP chain are removed by the 442 instruction [3] in Section 4.2. These bud segments are applicable to 443 common P2MP transport, and hence are considered as the default and 444 general purpose bud segments. 446 The concept of bud segment is also applicable to other types of local 447 processing on a transit leaf node, where the context of the local 448 processing cannot be derived from a packet's inner header. For 449 example, the node may want to forward packets over a particular 450 interface or tunnel, or based on a particular forwarding table or 451 policy. In such cases, a dedicated bud segment may be introduced to 452 serve each distinct scenario and indicate a specific context. These 453 bud segments are called special purpose bud segments. 455 The scale of special purpose bud segments per leaf node SHOULD be a 456 consideration in network design, as well as the mechanisms for 457 distributing these bud segments to controllers or all the root nodes. 459 7. IANA Considerations 461 This document requires IANA to allocate a value from the "Extended 462 Special-Purpose MPLS Label Values" registry for the EoC label. 464 The document also requires IANA registration and allocation for the 465 ISIS, OSPF and BGP extensions for bud segment advertisement. The 466 details will be provided in the next version of this document. 468 8. Security Considerations 470 This document introduces bud segments for leaf nodes to act as both 471 packet receivers and transit routers. A security attack may target 472 on a leaf node by constructing malicious packets with the node's bud- 473 SID. Such kind of attacks can be defeated by restricting bud segment 474 distribution and P2MP chain construction within the scope of a 475 controller and a given network. 477 9. Acknowledgements 479 This document leverages work done by Alexander Arseniev, Ron Bonica, 480 and G Sri Karthik Goud. 482 10. Contributors 484 Alexander Arseniev 486 Juniper networks 488 Email: aarseniev@juniper.net 490 Ron Bonica 492 Juniper networks 494 Virginia 496 USA 498 Email: rbonica@juniper.net 500 11. References 502 11.1. Normative References 504 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 505 Decraene, B., Litkowski, S., and R. Shakir, "Segment 506 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 507 July 2018, . 509 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 510 Decraene, B., Litkowski, S., and R. Shakir, "Segment 511 Routing with the MPLS Data Plane", RFC 8660, 512 DOI 10.17487/RFC8660, December 2019, 513 . 515 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 516 and Retiring Special-Purpose MPLS Labels", RFC 7274, 517 DOI 10.17487/RFC7274, June 2014, 518 . 520 [SRv6-SRH] 521 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 522 Matsushima, S., and D. Voyer, "IPv6 Segment Routing 523 Header", draft-ietf-6man-segment-routing-header (work in 524 progress), 2019. 526 [SRv6-Programming] 527 Filsfils, C., Garvia, P., Leddy, J., Voyer, D., 528 Matsushima, S., and Z. Li, "SRv6 Network Programming", 529 draft-ietf-spring-srv6-network-programming (work in 530 progress), 2019. 532 11.2. Informative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 540 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 541 May 2017, . 543 Authors' Addresses 545 Yimin Shen 546 Juniper Networks 547 10 Technology Park Drive 548 Westford, MA 01886 549 USA 551 Email: yshen@juniper.net 553 Zhaohui Zhang 554 Juniper Networks 555 10 Technology Park Drive 556 Westford, MA 01886 557 USA 559 Email: zzhang@juniper.net 561 Rishabh Parekh 562 Cisco Systems 563 San Jose, CA 564 USA 566 Email: riparekh@cisco.com 567 Hooman Bidgoli 568 Nokia 569 Ottawa 570 Canada 572 Email: hooman.bidgoli@nokia.com 574 Yuji Kamite 575 NTT Communications 576 Tokyo 577 Japan 579 Email: y.kamite@ntt.com