idnits 2.17.1 draft-leiwm-tsvwg-mpts-ar-07.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 (January 24, 2017) is 2647 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 255 -- Looks like a reference, but probably isn't: 'RFC5234' on line 2336 -- Looks like a reference, but probably isn't: 'RFC3264' on line 2316 == Unused Reference: '1' is defined on line 2428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (ref. '2') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '5') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '6') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '8') (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Lei 3 Internet-Draft W. Zhang 4 Intended Status: Experimental S. Liu 5 Expires: July 24, 2017 Northeastern University 6 January 24, 2017 8 A Framework of Multipath Transport System Based on 9 Application-Level Relay (MPTS-AR) 10 draft-leiwm-tsvwg-mpts-ar-07 12 Abstract 14 Multipath transport is an important way to improve the efficiency of 15 data delivery. This document defines a multipath transport system 16 framework in which application-level relays are deployed to provide 17 the conditions to enable multiple paths between source and 18 destination. In the proposed framework, endpoints are allowed to use 19 multiple paths, including the default IP path and relay paths, to 20 transport data in a single session. A relay path may via one or more 21 application-level relays which provide application-level relay 22 services for endpoints. This framework defines three kinds of logical 23 entities including user agent, relay server and relay controller. 24 Relay server provides relay service for user agents based on a local 25 path-table. Relay controller manages relay servers and relay paths. 26 User agent maintains multiple end-to-end paths which include a 27 default path and multiple relay paths. The framework also defines a 28 relay service control protocol named OpenPath protocol in control 29 plane to manage relay servers and relay paths, and a profile of 30 multipath transport protocol suite in data plane to facilitate 31 multipath data transport. The multipath transport system framework 32 can support various applications including applications requiring 33 timely delivery of real-time data such as streaming media, and 34 applications requiring ordered reliable delivery of stream of data 35 such as file transfer. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current 45 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 24, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1 Deployment and organization of relay controller and relay 75 server . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2 Relay path service provided by relay controller . . . . . . 10 77 4.3 End-to-end transmission paths managed by user agent . . . . 11 78 4.4 Relay service control protocol . . . . . . . . . . . . . . 12 79 4.5 Multipath transport protocol suite and profile . . . . . . 13 80 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1 Usage Scenario in SIP system . . . . . . . . . . . . . . . 17 82 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 19 83 6.1 Multipath session management . . . . . . . . . . . . . . . 19 84 6.2 Path management . . . . . . . . . . . . . . . . . . . . . . 20 85 6.3 Flow partitioning and scheduling . . . . . . . . . . . . . 21 86 6.4 Subflow packaging . . . . . . . . . . . . . . . . . . . . . 22 87 6.5 Subflow and flow recombination . . . . . . . . . . . . . . 22 88 6.6 Subflow and flow reporting . . . . . . . . . . . . . . . . 23 89 7. Relay Server Behavior . . . . . . . . . . . . . . . . . . . . 23 90 7.1 Connection Management and Registrations . . . . . . . . . . 24 91 7.2 Path-Table Management . . . . . . . . . . . . . . . . . . . 25 92 7.3 Path Validity Management . . . . . . . . . . . . . . . . . 27 93 7.4 Relay Service Management . . . . . . . . . . . . . . . . . 27 94 7.5 MPTP Packet Processing . . . . . . . . . . . . . . . . . . 28 95 7.6 Topology Discovery and Performance Measurement . . . . . . 28 96 8. Relay Controller Behavior . . . . . . . . . . . . . . . . . . 29 97 8.1 Relay Server Management . . . . . . . . . . . . . . . . . . 29 98 8.2 Topology Maintenance . . . . . . . . . . . . . . . . . . . 29 99 8.3 Relay Path Allocation . . . . . . . . . . . . . . . . . . . 30 100 9. OpenPath Protocol . . . . . . . . . . . . . . . . . . . . . . 31 101 9.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 31 102 9.1.1 Relay-to-Controller . . . . . . . . . . . . . . . . . . 31 103 9.1.2 Controller-to-Relay . . . . . . . . . . . . . . . . . . 32 104 9.1.3 User agent-to-Controller . . . . . . . . . . . . . . . 33 105 9.1.4 Symmetric . . . . . . . . . . . . . . . . . . . . . . . 34 106 9.2 Common Structures . . . . . . . . . . . . . . . . . . . . . 34 107 9.2.1 OpenPath Common Header . . . . . . . . . . . . . . . . 34 108 9.2.2 Common Body of OpenPath Failure Responses . . . . . . . 36 109 9.2.3 Transport Address Structure . . . . . . . . . . . . . . 37 110 9.3 Message Format of OpenPath Request and Success Response . . 37 111 9.3.1 HELLO . . . . . . . . . . . . . . . . . . . . . . . . . 37 112 9.3.2 START/STOP/BYE . . . . . . . . . . . . . . . . . . . . 38 113 9.3.3 ECHO . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 9.3.4 NOTIFY/DELETE_PATH . . . . . . . . . . . . . . . . . . 40 115 9.3.5 ADD_PATH/UPDATE_PATH . . . . . . . . . . . . . . . . . 41 116 9.3.6 ALLOCATE_PATH . . . . . . . . . . . . . . . . . . . . . 42 117 9.3.7 RELEASE_PATH . . . . . . . . . . . . . . . . . . . . . 45 118 9.3.8 FEATURES . . . . . . . . . . . . . . . . . . . . . . . 46 119 9.3.9 STATISTICS . . . . . . . . . . . . . . . . . . . . . . 46 120 10. MPTP Profile . . . . . . . . . . . . . . . . . . . . . . . . 46 121 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 46 122 10.2 MPTP Fixed Header Fields . . . . . . . . . . . . . . . . . 47 123 10.2.1 Fixed Header Fields of MPTP Data Packet . . . . . . . 47 124 10.2.2 Fixed Header Fields of MPTP Control Packet . . . . . . 49 125 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 51 126 11.1 Signaling MPTP Capability in SDP . . . . . . . . . . . . . 51 127 11.2 Relay Path Advertisement in SDP . . . . . . . . . . . . . 51 128 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 129 12.1 SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 52 130 13. Security Considerations . . . . . . . . . . . . . . . . . . . 53 131 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 132 14.1 Normative References . . . . . . . . . . . . . . . . . . . 53 133 14.2 Informative References . . . . . . . . . . . . . . . . . . 53 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 136 1. Introduction 138 For end-to-end multimedia session, multipath transport has more 139 benefits than single path transmission. Multiple disjoint (or 140 partially disjoint) paths could provide greater transmission 141 bandwidth, and redundancy among multiple disjoint paths increases 142 transmission reliability by protecting multiple paths from failure of 143 one, so multipath transport can promote quality of transmission 144 service. Moreover, from the perspective of whole network transmission 145 efficacy, multipath transport can achieve load balance and increase 146 the efficiency of the network resource usage. 148 In order to achieve multipath transport, the following two problems 149 need to be considered: 1) how to build multiple paths between 150 communication endpoints, and 2) given multipath paths, how to 151 implement multipath transport between communication endpoints. 153 The current underlying IP routing protocol can only build a single 154 transport path between endpoints. This implies that although the 155 Internet routing infrastructure is highly redundant, current 156 underlying routing protocols fail to fully utilize the network 157 redundancy. And it is nearly impossible to update protocol stack of 158 existing network devices to support multipath routing due to 159 tremendous cost. Now the main usage scenario of multipath transport 160 is based on multi-homed host, which requires at least one of 161 communicating endpoints is multi-homed. The multi-homed host 162 multipath usage scenario relies on the end host equipped with several 163 access networks, which is hard to be satisfied in practical 164 applications. 166 An alternative approach for establishing multiple paths between 167 source and destination is to provide support mechanisms in the 168 application layer while retaining the underlying network 169 infrastructure and end devices. This scheme of multipath transport is 170 a kind of overlay network technologies actually. Overlay networks 171 have emerged as an effective way to support new applications, as well 172 as protocols without any changes in the underlying network layer. 173 Multiple disjoint (partially disjoint) transmission paths, which pass 174 one or more application-level overlay nodes, can be established 175 between end hosts. This method is compatible with existing protocol 176 stack, and gets rid of the restrictions of physical network 177 conditions. Therefore, it is relatively easier to establish multipath 178 transport scenario. 180 This document defines a framework of multipath transport system based 181 on application-level relay (MPTS-AR). A large amount of application- 182 level overlay nodes are deployed to provide relay service to the 183 communicating endpoints. The upper application programs are provided 184 with opportunities to autonomously select one or multiple paths, 185 including the default IP path and relay paths, to transport data in a 186 session. A relay path may go through one or multiple overlay nodes 187 which provide relay services for endpoints. This framework defines 188 three kinds of logical entities including user agent, relay server 189 and relay controller, and describes their function blocks and 190 behaviors. The framework also defines a relay service control 191 protocol named OpenPath protocol in control plane to manage relay 192 paths, and a profile of multipath transport protocol suite in data 193 plane to facilitate multipath data transport. 195 Relay controller and relay servers constitute a relay service system, 196 which provides relay service to user agents. Relay controller is 197 responsible for managing relay servers, allocating relay paths, QoS 198 condition evaluation and so on. It also provides a unified access 199 interface of relay service to user agents or out-of-band signaling 200 entities. Main function of relay server is to forward the 201 application-level data flow, by receiving media stream from the 202 address and port of last hop, and then forwarding to the address and 203 port of next hop. A relay path may pass one or more relay servers. 205 OpenPath, relay service control protocol, mainly includes two kinds 206 of messages: the first is exchanged between relay controller and 207 relay server which is used to manage relay servers and relay paths. 208 Any application software or special server, which implements data 209 relay services and supports OpenPath protocol as described in this 210 document, can dynamically register to a relay controller and provide 211 relay service for user agents in the region of this relay controller. 212 The second is exchanged between relay controller and user agent or 213 out-of-band signaling entity which is used to manage relay path 214 including relay path inquiry, establishment, teardown, etc. 216 Transport requirements of various applications may be quite diverse. 217 These applications are sensitive to different routing metrics such as 218 latency, loss, throughput and so on. In order to support a variety of 219 applications, the proposed MPTS-AR needs to work with a suite of 220 multipath transport protocol (MPTP) which consists of multiple 221 application-specific MPTPs. Each application-specific MPTP is aimed 222 to meet the transmission requirements of a specific category of upper 223 applications. In order to extend easily a new application-specific 224 MPTP for an emerging application and simplify implementation of user 225 agents, this document gives a common profile for all application- 226 specific MPTPs. MPTP profile provides application-level multipath 227 routing mechanism which is common in all application-specific MPTPs. 228 All application-specific MPTPs MUST follow the common rules defined 229 by MPTP profile. This document gives the definition of MPTP profile. 230 Application-specific MPTPs are defined in companion documents. 232 Main principles for designing this framework include: 234 1) Establishment of multipath transport scenarios depends on the 235 relay service provided by relay service system. Relay server does not 236 care end-to-end transmission characteristics of data flows forwarded 237 by it. Therefore, a variety of upper applications can use multipath 238 transport services provided by the relay service system. 240 2) Management and service access interfaces of relay service are 241 standardized so that any organizations and individuals can provide 242 specialized relay services. 244 3) The MPTP profile defines common rules of multipath transport based 245 on application-level relay for various upper applications. To support 246 a specific category of upper applications, a corresponding 247 application-specific MPTP should be defined in an additional 248 document. 250 2. Terminology 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in RFC 2119 [RFC2119]. 256 3. Definitions 258 1) Subflow: flow of data packets along a specific path, i.e., a 259 subset of the packets belonging to a data flow. The combination of 260 all subflows forms the complete original data flow. Typically, a 261 subflow should map to a unique path. 263 2) Session: an association between two participants transmitting 264 data. An endpoint may be involved in multiple sessions at the same 265 time. For example, in a multimedia session, each medium is typically 266 carried in a separate real-time transport protocol (RTP) [3] session 267 which is a type of 'session' defined here. Another typical example of 268 session is to transfer one or multiple files between two endpoints. 269 This framework allows the variations defined here for different 270 applications. 272 3) Multipath Session: a special type of session in which the original 273 data flow is split into multiple subflows and each subflow is 274 forwarded along a unique path. 276 4) Path: sequence of logical links between a source and a 277 destination. We define it by a set of addresses. All available paths 278 for a session include a default path and one or more relay paths. 280 5) Default path: a path between a sender and a receiver, which is 281 same as the path negotiated and established by a normal session. In 282 Session Initiation Protocol (SIP) [4] and Session Description 283 Protocol (SDP) [5] case, the default path is determined by the c= and 284 m= lines in SDP during session setup. If either the source or the 285 destination is not behind a symmetric NAT, the default path may be 286 the direct network path between the source and the destination. 287 Otherwise, it may traverse a third-party node, such as a TURN server 288 or a media server which is responsible for relaying packets. 290 6) Relay path: a path via one or multiple relay servers between a 291 source and a destination. A relay path is defined by a sequence of 292 (S, R1, ..., Rm, D), where Ri denotes the address of the i-th relay 293 server and m denotes the number of relay servers in this path. 295 7) Candidate path: a path that is either a default path or a relay 296 path. 298 8) Active path: a path that carries media data. 300 9) User Agent: a logical entity that can act as either a sender or a 301 receiver. A sender is responsible for managing all candidate paths 302 and multipath session, partitioning and scheduling subflows, and 303 packaging MPTP packets. A receiver is responsible for recombinating 304 subflow packets and sending back QoS feedback to the sender for each 305 subflow. The behavior of a user agent is further defined in Section 306 6. 308 10) Relay server: an intermediary entity that primarily plays the 309 role of forwarding subflow packets according to a Path-Table. Relay 310 server receives subflow packets from its upstream entity of the 311 subflow that the received packets belong to, obtains the next-hop 312 transport address based on the matching results in the Path-Table, 313 and forwards the packets to the corresponding next-hop transport 314 address. The behavior of a relay server is further defined in Section 315 7. 317 11) Path-Table: a table consisting of a set of path entries, which 318 may be added, updated or deleted by a remote relay controller via 319 OpenPath protocol. Each relay server maintains its own path-table. 321 12) Relay Controller: a logical entity that manages all relay servers 322 in its region and allocates relay paths for each session. The 323 behavior of a relay controller is further defined in Section 8. 325 13) Overlay Link: the connection between two relay servers. It is 326 usually composed of one or more physical links. 328 4. Overview 330 In the multipath transport system based on application-level relay, 331 relay server provides application-level data forwarding service, 332 which can used to establish multiple relay paths between 333 communication endpoints to achieve multipath transport. With 334 appropriate multipath transport control mechanisms and protocols, not 335 only can it achieve higher quality of end-to-end transmission 336 service, but it balance network load and enhance efficiency of the 337 network resource usage. 339 Figure 1 illustrates the structure of the proposed multipath 340 transport system framework and the relationship among user agent, 341 relay server and relay controller. Relay controller and relay server 342 constitute the relay service system which provides relay service to 343 user agent. User agent maintains multiple end-to-end relay paths, 344 and dispatches data flow along multipath paths following MPTP 345 protocol suite. 347 (1)Out-of-band Signaling +-----------------+ (1)Out-of-band Signaling 348 +-------------------->| Out-of-band |<-------------------+ 349 | | Signaling Server| | 350 | +-----------------+ | 351 | ^ | 352 | |(1)OpenPath | 353 | ...............|................. | 354 | . V . | 355 |or (2)OpenPath . +------------------+ . | 356 | +----------------->| Relay Controller | . | 357 | | . +------------------+ . | 358 | | . ^ . | 359 | | . | . | 360 V V . | . V 361 +------------+ . |OpenPath . +------------+ 362 | User Agent | . | . | User Agent | 363 | (Sender) | . | . | (Receiver) | 364 +------------+ . V . +------------+ 365 || . +-----------------+ . ^ ^ 366 || . | Relay server | . | | 367 || . +-----------------+ | . | | 368 |+------------------->| Relay server |--+ . | | 369 | MPTP . +-----------------+ |----------------+ | 370 +----------------->| Relay server |--+ . MPTP | 371 MPTP . | |---------------------+ 372 . +-----------------+ . MPTP 373 . relay service system . 374 ................................. 376 Figure 1. The structure of the multipath transport system framework 377 based on application-level relay (MPTS-AR) 379 4.1 Deployment and organization of relay controller and relay server 381 The relay controller is the central component of the relay service 382 system. It provides service access and management interfaces of relay 383 service to user agents and relay servers. The main functions of relay 384 controller are to manage relay servers, evaluate the QoS conditions 385 of relay paths, and provide relay path service to user agents (or 386 provide relay path service to user agent indirectly through out-of- 387 band signaling server). Relay controller that is usually deployed in 388 the core of the network by the overlay service provider usually 389 possess high-capacity computing, storage, and bandwidth resources. 391 As the number of user agents and relay servers increases, the 392 calculating and storing workload of relay controller also increases, 393 which would cause the relay controller become a bottleneck within the 394 system and reduce the scalability of MPTS-AR system. 396 When there are a large number of user agents or relay servers, 397 multiple relay controllers can be deployed and each of them provides 398 management service for part of user agents and relay servers. Relay 399 controller cluster may be organized in a variety of ways, such as 400 flat mode and hierarchical mode. In flat mode, all relay controllers 401 are equivalent. Each relay controller is in charge of managing part 402 of relay servers distributed across the network and providing relay 403 path service for part of user agents distributed across the network. 404 They work independently without sharing any information between them. 405 User agents and relay controllers can get the address information of 406 relay controllers through a variety of ways such as by querying DNS 407 SRV records. In hierarchical mode, relay controllers are divided into 408 two types: master relay controllers and slave relay controllers. The 409 master relay controller has the global view of the system. It divides 410 relay servers into several fields each of which is managed by one 411 slave relay controller. When the source and the destination of a data 412 flow are located into different fields, the allocation process of 413 relay paths is completed coordinately by a master relay controller 414 and several slave relay controller. 416 Relay servers provide data relay service to the communicating agents. 417 Considering the efficiency of the forwarding service, MPTS-AR adopts 418 UDP as the underlying transport protocol. Relay servers may be 419 deployed in a variety of ways. In one way, a number of Internet 420 service providers (ISP) can actively deploy proprietary overlay nodes 421 with high network bandwidth and computing performance in their 422 domains and offer them to overlay service providers (OSP). ISPs may 423 also provide additional support for the operation of the overlay 424 network to the OSP and charge OSP for the resources and support 425 provided. The OSP can lease a number of overlay nodes from multiple 426 ISPs and deploy multipath transport system on top of them.The OSP 427 offers multipath transport service to interested users and charges 428 the users for the services. In this way, overlay networks can be 429 enhanced with available routing information to reduce path quality 430 measurement costs and to provide best routes. In another way, the 431 participating nodes that access the same application may also self- 432 organize to form a dynamic overlay network among which the nodes with 433 higher performance can provide relay service to others. The 434 organization of relay servers is a kind of typical overlay network 435 technology. Overlay network model of relay servers that is closely 436 related to the allocation of relay paths is outside the scope of this 437 document. This document does not recommend any specific overlay 438 network model and only rules that all relay servers need to register 439 to a relay controller and provide data relay service to user agents. 441 4.2 Relay path service provided by relay controller 443 All relay servers register to a relay controller in their region. 444 Relay controller is responsible for managing the relay servers and 445 providing direct or indirect relay path services to the user agent by 446 OpenPath protocol including establishing, inquiring, and removing of 447 relay paths. 449 Considering the execution efficiency, the relay path is designed to 450 be unidirectional. A bidirectional data flow, such as in a 451 conversational use-case, is regarded as two independent 452 unidirectional flows in opposite directions. Relay paths 453 are assigned for each unidirectional flow. 455 User agent sender, who is responsible for sending out data flow, and 456 relay servers need to know the relay path information so they can 457 correctly forward subflow data along a particular relay path. An 458 alternative approach, similar to source routing, is that the user 459 agent sender can store the entire route in MPTP packet headers. Each 460 intermediate node will simply examine the headers of a received 461 packet and forward it to the next node as indicated in the source 462 route. The advantage of the method is to simplify the implementation 463 of relay servers. They need not store any path information and can 464 perform routing of MPTP packets only based on MPTP packet headers. 465 But this method introduces traffic overhead considerably, especially 466 when the payload traffic is relatively small. 468 In practice, the user agent sender and relay servers need not to know 469 the complete information of the associated path. They just need to 470 know the next-hop transport address for each path associated with 471 them. A pair of transport address comprises one network address plus 472 one port. When receiving OpenPath path allocation request messages 473 from user agents directly or indirectly (for example via signaling 474 server such as SIP or RTSP), relay controller generates a set of 475 disjoint relay paths based on information carried by the OpenPath 476 path allocation request message including the media types, quality of 477 experience (QoE) expectations or requirements, the number of relay 478 paths expected, and so on. Relay controller associates a unique path 479 identifier to each relay path. On the one hand, relay controller 480 instructs the corresponding relay servers to assign the appropriate 481 resources for incoming data forwarding. On the other hand, relay 482 controller sends OpenPath response message back to the service 483 requester. Usually, the response message includes the path 484 identifier, the relay service address of first-hop relay server and 485 instant QoS of each path. This document neither defines a uniform 486 relay path generation algorithm, nor recommends QoS evaluation method 487 of relay path. These methods can be designed by the overlay service 488 provider. 490 Relay controller needs to maintain the mapping between the user agent 491 and the allocated relay paths. When receiving OpenPath path removal 492 request messages, relay controller instructs the associated relay 493 servers to release resources and generates a response message back to 494 the requester. 496 4.3 End-to-end transmission paths managed by user agent 498 End-to-end transmission paths between user agents includes two types: 499 1) default path (DP), which does not go through any relay server; 2) 500 relay path (RP), which goes through one or more relay servers. 502 In order to establish multiple end-to-end transmission paths, user 503 agent sender, needs to collect candidate paths before transmitting 504 data. As shown in figure 1, this document provides two alternative 505 ways to be used for collecting candidate paths by the user agent 506 sender. In the first way, the user agent sender obtains candidate 507 paths from the out-of-band signaling used for establishing an 508 association between the user agent sender and user agent receiver. 509 More specifically, user agents use a kind of out-of-band signaling 510 (e.g., SIP, Real-Time Streaming Protocol (RTSP) [6]) to negotiate and 511 establish a session with the remote peer before transmitting data. 512 The signaling server, which out-of-band signaling passes through 513 during session setup, is extended to support the access interfaces of 514 relay path service provided by OpenPath protocol. The signaling 515 server requests the relay controller to allocate relay paths for the 516 session to be established on behalf of the user agent sender. If 517 successful, the signaling server inserts the information of the 518 allocated relay paths into corresponding signaling messages to inform 519 the participating user agents. In the second way, the user agent 520 sender obtains candidate paths through direct interaction with the 521 relay controller using OpenPath Protocol. The advantage of the first 522 way is to avoid a large number of connections of the relay controller 523 with user agents, and improve the security of the relay controller 524 through limiting communication only with the trusted signaling 525 server. 527 As mentioned above, relay path is designed to be unidirectional. A 528 bidirectional data flow is regarded as two independent unidirectional 529 flows in opposite directions. Two participating nodes of the 530 bidirectional session are the user agent sender of the corresponding 531 unidirectional flows respectively. Both user agent senders needs to 532 collect candidate paths for corresponding unidirectional flow. 534 After collecting multiple end-to-end transmission paths, user agent 535 sender needs to evaluate the quality of the part of a relay path from 536 the user agent sender itself to the first-hop relay server (the first 537 relay server on a relay path) for each relay path. Combined with path 538 QoS information carried by OpenPath path allocation response message, 539 user agent sender then calculates end-to-end transmission qualities 540 of all relay paths, which are used as the basis of subsequent path 541 selection and load distribution. 543 During the lifecycle of multipath transport session, user agent 544 sender usually needs to dynamically evaluate QoS condition of all 545 paths including default path and relay paths using MPTP and 546 corresponding measurement mechanism. Dynamic path quality information 547 can be used to optimize load distribution process and achieve a 548 better transmission service quality. 550 User agents should establish a multipath session before using 551 multiple paths to transport data flow. It can be set up in many 552 possible ways e.g., during session establishment, or at anytime 553 during the session. To reduce session startup time, the user agent 554 sender can start transporting data via the default path and then 555 perform path connectivity checks for relay paths. If there are one or 556 multiple available relay paths, the use agent sender updates the 557 single-path session to a multipath session. 559 4.4 Relay service control protocol 561 Different from multipath transport scenario based on multi-homed 562 hosts, in the multipath transport scenario based on application-level 563 relay, the generation and normal operations of relay paths depend on 564 the relay service system which includes relay controller and relay 565 server. 567 Relay controller provides control functions of relay service, and 568 relay sever provides executive functions of relay service. Relay 569 server needs to report the status to the relay controller, and relay 570 controller needs to control the behaviors of relay servers. In 571 addition, in order to provide relay path service to user agents or 572 out-of-band signaling server, relay controller needs to provide relay 573 service access interfaces. Therefore, this document defines a relay 574 service control protocol named OpenPath, which provides interfaces 575 among relay controller, relay server and user agents or out-of-band 576 signaling server. 578 The definition of OpenPath protocol will promote the progress of 579 standardization of the application-level multipath relay service. As 580 long as OpenPath protocol and MPTP are followed, third-party relay 581 servers implemented and deployed by any organization and individual 582 can interact with relay controller and provide relay service to user 583 agents. This document defines OpenPath protocol in detail. 585 4.5 Multipath transport protocol suite and profile 587 Existence of multiple end-to-end transmission paths between 588 participating nodes is only the basis of enabling multipath 589 transmission. User agents need to use a kind of multipath transport 590 protocol to exchange data via multiple transmission path in a 591 session. The design of this multipath transport protocol needs to 592 focus on considering the following factors: 1) express multipath 593 transport control mechanism fully, such as subflow partition and 594 recombination mechanism, multipath routing, etc. 2) meet various 595 transport requirements of different overlay applications, such as 596 real-time transport requirement, reliable transport requirement, etc. 597 3) meet transport requirements of relay server. As relay server only 598 supports efficient UDP forwarding, multipath transport protocol is 599 required to be a UDP-based application-layer protocol. 4) minimize 600 the overhead of multipath transport control. The ratio of transport 601 control messages should be as small as possible. Some existing 602 multipath transmission control protocols, including MPTCP [7], SCTP 603 [8], can not meet the aforementioned requirements. In addition, 604 multiple multipath transport protocols need to be designed to meet 605 different transport requirement of overlay applications. 607 In this document, multipath transport protocol (MPTP) is designed to 608 be a protocol suite which consists of one MPTP profile and multiple 609 application-specific MPTPs. The MPTP profile is aimed to provide 610 application-level multipath routing mechanism and each application- 611 specific MPTP is aimed to meet the transmission requirements of a 612 specific category of upper applications. All application-specific 613 MPTPs MUST follow MPTP profile defined in this document. Relay 614 servers need to support MPTP profile, and user agents need to support 615 MPTP profile and one or multiple application-specific MPTPs. 617 MPTP is a UDP-based application-layer transport protocol. The 618 protocol stack architecture of MPTP is shown in figure 2. 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Applications | 622 |(VoIP, video conference, streaming, file transfer,...) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | MPTP | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | UDP | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | IP | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 2. The protocol stack architecture of MPTP 633 In network protocol stack, the transport layer provides end-to-end 634 communication services for applications. Reliable transport 635 protocols, such as TCP and SCTP, are not particularly suitable for 636 real-time applications such as streaming media and real-time 637 multiplayer games. And they are complex and can be a problem for 638 relay servers which provide relay service for huge numbers of user 639 agents. In contrast, UDP only provides checksums for data integrity, 640 and multiplexing for different applications. It delegates other 641 functions to the above application programs. Therefore it typically 642 gives higher throughput and shorter latency. Based on these 643 considerations, MPTP uses UDP as underlying transport protocol. Each 644 UDP datagram carries one MPTP packet. On the one hand, this design 645 decision simplifies the behaviors and enhances service capabilities 646 of relay servers. In other words, relay server works in a stateless 647 manner and provides the UDP-based relay service. On the other hand, 648 all upper applications, that need either timely delivery or reliable 649 delivery, can use the transport service provided by MPTP. The 650 delivery requirements of upper application need to be meet by MPTP 651 profile and application-specific MPTPs. 653 In addition to carrying payload data passed from upper application 654 programs through multiple paths, MPTP also need to provide path 655 control functions including keeping path alive and monitoring the 656 quality of data delivery on each path. 658 5. Usage Scenarios 660 The multipath transport system framework based on application-level 661 relay can provide many application scenarios including point-to- 662 point, many-to-one and one-to-many communications. These 663 applications could be delay sensitive or reliability sensitive, such 664 as real-time communication, parallel streaming media, file transfer 665 or file sharing. 667 Figure 3 illustrates a point-to-point multipath session. There are 668 three paths between source and destination, including the default 669 path, one relay path via one relay server and another relay path via 670 two relay servers. User agent sender can choose a data partitioning 671 method according to its particular requirements. Then, each flow is 672 assigned to a path. The user agent receiver reassembles the received 673 flows using a resequencing buffer to retrieve the reconstructed flow 674 which is delivered to the above application. 676 Relay path(A, Relay-1, B) 677 +-----------+ 678 +-------------------->| Relay-1 |-----------------------+ 679 | +-----------+ | 680 | V 681 +--------+ Default path(A,B) +--------+ 682 | User A |<----------------------------------------------->| User B | 683 +--------+ +--------+ 684 | ^ 685 | Relay path(A, Relay-2, Relay-3, B) | 686 | +-----------+ +-----------+ | 687 +---->| Relay-2 |-------------------->| Relay-3 |-----+ 688 +-----------+ +-----------+ 690 Figure 3. A point-to-point multipath session 692 A wide range of applications require data transmission from 693 geographically distributed sources to one destination. For instance, 694 large volume data of high definition movies are stored at multiple 695 geographically distributed locations. The audiences need to retrieve 696 and integrate data from several locations. This usage scenario can be 697 completed by a many-to-one multipath session, which is depicted in 698 Figure 4. In the figure, the user agent receiver streams different 699 portions of a video from three servers concurrently. The path between 700 the server and the user agent receiver may go through one or more 701 relay servers. 703 +---+ 704 | A |----------------------------------------------------+ 705 +---+ | 706 | 707 V 708 +---+ +-----------+ +---+ 709 | B |------------------| Relay-1 |------------------>| D | 710 +---+ +-----------+ +---+ 711 ^ 712 | 713 +---+ +-----------+ | 714 | C |------------------| Relay-2 |---------------------+ 715 +---+ +-----------+ 717 Figure 4. A many-to-one multipath session 719 Many video applications are typically characterized by a wide range 720 of connection qualities and receiving devices which are with 721 different capabilities ranging from cell phones with small screens 722 and restricted processing power to high-end PC with high-definition 723 display. These systems are usually adopting layered coding. Layered 724 coding enables the encoding of a high-quality video bit stream 725 containing one or more subset bit streams that can themselves be 726 decoded independently. This usage scenario can be completed by a 727 one-to-many multipath session, which is depicted in figure 5. A video 728 source is encoded into multiple streams, each of which is transported 729 by a source tree for video multicast. 731 +---+ 732 +------------------------->| A | 733 | +--->+---+ 734 | | 735 +-----------+ | 736 +------------------->| Relay-1 |--------------|------+ 737 | +-----------+ | | 738 | | | | 739 | | | V 740 +---+ +------------------+ | +---+ 741 | S | | | | B | 742 +---+ +------------------|--+ +---+ 743 | | | ^ 744 | | | | 745 | +-----------+ | | 746 +------------------->| Relay-2 |-----------|---------+ 747 +-----------+ | 748 | | 749 | +------>+---+ 750 +------------------------->| C | 751 +---+ 753 Figure 5. A one-to-many multipath session 755 5.1 Usage Scenario in SIP system 757 Figure 6 depicts a kind of usage scenario in which SIP is used as a 758 separate signaling to advertise relay paths information. 760 (1)INVITE +-----------------+ (3)INVITE 761 +-------------------->| |----------------------+ 762 | +-----------------| SIP Server |<-----------------+ | 763 | | (6)200OK +-----------------+ (4)200OK | | 764 | | ^ | | 765 | | |(2)(5) | | 766 | | V | | 767 | | +-----------------+ | | 768 | | | Relay Controller| | | 769 | | +-----------------+ | | 770 | | ^ ^ ^ | | 771 | | (2)(5) | |(2)(5) | (2)(5) | | 772 | V +-------+ V +-------+ | V 773 +--------+ P-1/P-3| +------------+ | P-1/P-3 +--------+ 774 | User A |<-------|------>| Relay-1 |<-------|--------->| User B | 775 +--------+ | +------------+ | +--------+ 776 ^ | | ^ 777 | V V | 778 | +-----------+ +-----------+ | 779 +---->| Relay-2 |<------------------->| Relay-3 |<-----+ 780 P-2/P-4 +-----------+ +-----------+ P-2/P-4 782 Figure 6. Usage scenario for multipath transport 783 system framework in SIP System 785 (1) User A sends an INVITE to the SIP server that serves her domain. 787 (2) SIP server extracts the current addressable locations of the 788 caller and the callee, and the media information including media 789 types and listed media codecs. Then SIP server sends an Openpath path 790 allocation request, ALLOCATE_PATH, carrying the above information to 791 the relay controller and requests it to assign the appropriate relay 792 paths for the media flow from user B to user A. In this example, the 793 relay controller selects two relay paths for the media flow from user 794 B to user A. They are (B, Relay-1, A) and (B, Relay-3, Relay-2, A), 795 named P-1 and P-2 respectively. And each relay path is associated 796 with a globally unique path identifier, named PID-1 and PID-2 797 respectively. The relay controller sends each of the three selected 798 relay server an ADD_PATH request message of OpenPath protocol. 799 ADD_PATH request includes the corresponding path identifier and 800 next-hop transport address of the receiving relay server. For 801 Relay-1, the path identifier is PID-1 and the next-hop transport 802 address is the current addressable location of user A. For Relay-2, 803 the path identifier is PID-2 and the next-hop transport address is 804 the current addressable location of user A. For Relay-3, the path 805 identifier is PID-2 and the next-hop transport address is Relay-2's 806 IP address and relay service port. 808 (3) SIP server inserts the path identifiers and the next-hop 809 transport addresses of user B into SDP body of INVITE and forward the 810 modified INVITE to user B. The next-hop transport addresses of user B 811 for P-1 and P-2 are separately the rely address of Relay-1 and 812 Relay-3. 814 (4) User B answers the call and sends back a 200 OK response. 816 (5) In the same way, SIP server obtains the allocated relay paths 817 for the media flow from user A to user B from the relay controller. 818 In this example, the relay controller assigns the same relay paths 819 with opposite direction for the media flow from user A to user B 820 based on symmetry principle. They are (A, Relay-1, B) and (A, 821 Relay-2, Relay-3, B), named P-3 and P-4 respectively, associated with 822 the path identifiers of PID-3 and PID-4. The relay controller sends 823 an ADD_PATH request message to each of the three selected relay 824 servers. For Relay-1, the path identifier is PID-3 and the next-hop 825 transport address is the current addressable location of user B. For 826 Relay-2, the path identifier is PID-4 and the next-hop transport 827 address is Relay-3's IP address and relay service port. For Relay-3, 828 the path identifier is PID-4 and the next-hop transport address is 829 the current addressable location of user B. 831 (6) SIP server inserts the path identifiers and the next-hop 832 transport addresses of user A into SDP body of 200 OK response and 833 forwards it to user A. The next-hop transport addresses of user A for 834 P-3 and P-4 are separately the rely address of Relay-1 and Relay-2. 836 Through the signaling process above, user A and user B separately 837 obtain three candidate paths including the default path and two relay 838 paths as the sending peer of the corresponding media flow. After 839 connectivity check, user A and user B can take advantage of multiple 840 paths to transport the media flow. 842 6. User Agent Behavior 844 Given multiple paths, user agent needs to provide essential support 845 for multipath transport, including session and path management, flow 846 partitioning and scheduling, subflow recombination, QoS feedback for 847 each subflow. 849 6.1 Multipath session management 851 In general, a session needs to be established between two 852 participants before transmitting data. At the same way, a multipath 853 session needs to be established before transporting data on multiple 854 paths. The multipath session setup uses a way of out-of-band 855 (e.g., SDP in SIP or RTSP). The capability exchange and relay path 856 advertisement should be done during the signaling process. A 857 multipath session may be setup from the beginning, or may be upgraded 858 from a normal single path session. 860 6.2 Path management 862 The user agent sender obtains the default path from the out-of-band 863 signaling for the session setup. In SIP/SDP case, the default path is 864 determined by the c= and m= lines in SDP. It may be the direct 865 network path between the sender and the receiver, or may traverse a 866 third-party node, such as a TURN server or a dedicated relay server. 867 For the latter, IP address and port of the third-party node is in the 868 c= and m= lines in SDP. The path identifier of the default path is 869 set to zero. 871 As stated in Section 5, the user agent sender can use two alternative 872 ways to collect candidate relay paths. One way is that the user agent 873 sender obtains candidate relay paths from the out-of-band signaling 874 for the session setup. The signaling server, which out-of-band 875 signaling passes through during session setup, requests the relay 876 controller to allocate relay paths for the session to be established 877 using OpenPath protocol. And then the signaling server inserts the 878 information of the allocated relay paths into corresponding signaling 879 messages to inform the participating user agents. Another way is that 880 the user agent sender obtains candidate paths through direct 881 interaction with the relay controller using OpenPath Protocol. 883 There may be one or multiple data flows in a single session. If there 884 are multiple flows in a session, user agent should determine which 885 flows to be multipath transmitted. For example, there may be one 886 audio media flow and one video media flow in an oncoming multimedia 887 session. User agent may select single transmission for audio media 888 flow and multipath transimission for video media flow according to 889 the bandwidth requirements. If multiple flows in a session need to be 890 multiple transmitted, user agent sender or signaling server can 891 request controller server to allocate relay paths for all flows at 892 once. 894 The user agent sender needs to perform path probes to determine if 895 the path is available and if so, obtains the transmission quality of 896 the path at the same time. After obtaining a new candidate path, the 897 user agent sender first performs path probe process, if the path is 898 available, marks it available and puts it into the available path 899 list ordered based on a decreasing priority level; if the path is not 900 available, marks it unavailable and puts it into the unavailable path 901 list. The user agent sender will periodically perform path probes for 902 all the paths in available path list to actively detect path failure 903 and perceive the dynamic changes to the path. If the probe process 904 for a particular path fails, the path will be marked unavailable and 905 removed from the available path list to the unavailable path list. 906 The user agent sender should also perform path probes for the paths 907 in unavailable path list in a longer cycle. If the probe process for 908 a particular path successes, the path will be marked available and 909 removed from the unavailable path list to the available path list. 911 If no data is received on a relay path within a given time, relay 912 servers will withdraw the corresponding resources allocated for this 913 path. Therefore, all the relay paths should be kept alive actively by 914 the user agent sender. To meet this requirement, the user agent 915 sender SHOULD send MPTP keep-alive packets periodically for both 916 active paths and non-active paths. 918 Using the information in the subflow MPTP reports, a user agent 919 sender can monitor delivery quality of active paths. If failure 920 (e.g., errors, unreachability, and congestion) happens in an active 921 path, the user agent sender may perform flow repartitioning and 922 spread the payload across other active paths, or may select a new 923 path from the available path list to replace the failure path. 925 6.3 Flow partitioning and scheduling 927 This document does not limit the usage of multiple paths. User agent 928 sender may concurrently use multiple paths to obtain higher 929 throughput, or may send all traffic on a specified path while all 930 other available paths are used only rarely to enhance resilience 931 (e.g., for retransmission, for error-repair, or for redundancy 932 packets). User agent sender MUST only use the default path and the 933 relay paths in available path list as the active path. How to use 934 multiple paths, concurrently, redundantly, or mixedly, is related to 935 the transmission requirements of the flow. How to select multiple 936 paths among all available paths and how many paths to use 937 concurrently or redundantly are outside the scope of this document. 939 If multiple paths are used concurrently, the original data stream 940 should be divided into several substreams. Flow partitioning methods 941 are outside the scope of this document. Application-specific MPTP 942 documents may introduce some flow partitioning methods for specific 943 applications. A simple flow partitioning scheme is to assign packets 944 to multiple subflows using the round-robin algorithm. Specifically, 945 the original data stream is first divided into blocks of equal-sized 946 temporal or spacial length. Then, a subflow is assembled by picking 947 blocks periodically from the original blocks in an increasing order. 948 This method is simple and can be applied to all of the upper 949 applications. However, the data are treated equally and not 950 distinguished based on their different importance in terms of the 951 whole data flow. And great correlations exist among subflows which 952 are sent along paths with different transport capacity. 954 User agent sender should associate a subflow with an active path 955 based on a scheduling strategy. A scheduling policy should jointly 956 consider various factors including the estimated path bandwidth 957 information, the path reception statistics (e.g. RTT, loss-rate, 958 delay etc.), the relative importance of subflow data and so on. Due 959 to the changes in path characteristics, user agent sender should be 960 able to change its scheduling strategy during an ongoing session to 961 fully explore the potential of multipath transport. 963 6.4 Subflow packaging 965 In a multipath session, user agent sender formats data flow into MPTP 966 data packets following MPTP profile defined in this document and the 967 corresponding application-specific MPTP defined in one application- 968 specific MPTP documents. Then the user agent sender dispatches MPTP 969 data packets along corresponding relay paths. 971 The common header of MPTP packets includes three key fields: path 972 identifier, subflow-specific sequence number (SSSN) and flow sequence 973 number (FSN). The path identifier of a relay path, which is globally 974 unique, is generated by the relay controller. The path identifier of 975 the default path is fixed to zero. The path identifier is used to 976 identify a specific path by the user agent sender and relays. 977 Meanwhile, the path identifier is also used to identify a subflow by 978 the user agent receiver. 980 Subflow-specific sequence number is the sequence number of a MPTP 981 data packet in a specific subflow. It is used to help calculate the 982 quality of data delivery such as fractional losses, jitter, RTT, etc, 983 for each path. The initial subflow sequence number is randomly 984 generated when the subflow is first established in the multipath 985 session. 987 Flow sequence number is the sequence number of a MPTP data packet in 988 an original flow. It is used to recombine the original flow. The 989 initial flow sequence number is randomly generated when the multipath 990 session is first established. 992 6.5 Subflow and flow recombination 994 The user agent receiver recombines the original data flow according 995 to MPTP data packets received from multiple paths. The user agent 996 receiver first restores the order of each subflow using path 997 identifier and subflow sequence number in MPTP data packet headers. 998 The user agent receiver then restores the order of the original flow 999 using flow sequence number. Concrete implementation work for subflow 1000 and flow recombination is different according to specific 1001 applications. This work SHOULD be defined in detail in application- 1002 specific MPTP documents. 1004 6.6 Subflow and flow reporting 1006 In order to monitor the quality of path delivery and to meet specific 1007 requirements of some kind of applications, user agents SHOULD 1008 generate MPTP reports for per subflow to provide subflow information. 1009 The user agent sender generates MPTP Subflow Sender Reports (SSR) for 1010 each unique subflow and sends them along the same path as the MPTP 1011 data packets in this subflow. As the relay path is unidirectional and 1012 the default path is bidirectional, the user agent receiver generates 1013 MPTP Subflow Receiver Reports (SRR) for each unique subflow and sends 1014 them along the default path. 1016 Although MPTP SSRs and SRRs are not sent along the same path, 1017 they still can be used to measure the quality of path delivery. For 1018 example, the calculated round-trip propagations to the user agent 1019 receiver along different paths using MPTP SSRs and SRRs still 1020 can correctly represent relative size of transmission delays of 1021 different paths. 1023 Delivery qualities of individual paths can not present the 1024 integrated efficiency of multipath transport completely and 1025 precisely. Besides subflow reports, the user agent receiver also 1026 needs to generate flow recombination reports for the whole received 1027 flow and feed them back to the user agent sender. As above, the flow 1028 recombination reports also need to be sent to sender along the 1029 default path. 1031 When user agent generates MPTP report packets is outside the scope of 1032 this document. It SHOULD be defined in detail in application-specific 1033 MPTP documents. In general, timely MPTP reports are necessary for 1034 multipath transport environments. MPTP reporting interval should be 1035 frequent enough for user agents to quickly adapt to path fluctuation 1036 and transmission errors. Meanwhile the traffic overhead introduced by 1037 MPTP reporting SHOULD also be taken into account when designing an 1038 application-specific MPTP for some specific applications. 1040 In addition, what MPTP report packets contain and what to do when 1041 receiving an MPTP report packet are related to the requirements of 1042 specific application programs. They are outside the scope of this 1043 document and SHOULD also be defined in detail in application-specific 1044 MPTP documents. 1046 7. Relay Server Behavior 1047 Relay server performs MPTP packets lookups and forwarding based on a 1048 local Path-Table. Relays are managed by the relay controller over 1049 connections using a protocol referred to as OpenPath protocol. 1051 7.1 Connection Management and Registrations 1053 Relay server communicates with the relay controller over a connection 1054 which may be encrypted using TLS or run directly over TCP. Relay 1055 server initiates a standard TLS or TCP connection to the relay 1056 controller. Relay server can get the IP address of the relay 1057 controller in a number of ways, such as manual configuration, DNS 1058 domain name queries and so on. 1060 When a connection is established, relay server completes the 1061 registration process by exchanging HELLO messages. The version field 1062 in HELLO request is set to the highest OpenPath protocol version 1063 supported by the relay server. Relay controller needs to check the 1064 included OpenPath protocol version in HELLO request. If the version 1065 is not supported, relay controller responds to the HELLO with a 1066 failure response. 1068 The relay server identifier field is set to zero in the initial HELLO 1069 request. This indicates that it is the first time for this relay 1070 server to register with the relay controller. The relay controller 1071 needs to assign a unique identifier for this relay server and insert 1072 the assigned relay server identifier in the corresponding HELLO 1073 response message. Subsequent HELLO request messages may carry the 1074 relay server identifier directly. 1076 The HELLO request contains the IP address and port of the relay 1077 server for the relay service. 1079 If a failure response to the HELLO message is received, relay server 1080 then terminates the connection. Otherwise, the connection proceeds 1081 and the relay server may start relay service. 1083 During the lifetime of the connection, ECHO requests should be sent 1084 periodically from either relay server or relay controller, and the 1085 request receiver must return an ECHO reply. 1087 After connection establishment, relay server may receive FEATURES 1088 requests from relay controller. It must respond with a FEATURES reply 1089 that specifies its capabilities. 1091 During the lifetime of the connection, relay controller may 1092 periodically collect statistics from a relay server by STATISTICS 1093 requests. The relay server must respond with a STATISTICS reply that 1094 specifies its current statistics. 1096 7.2 Path-Table Management 1098 The Path-Table contains a set of path entries each of which 1099 corresponds to an associated relay path. Each path entry consists of 1100 match fields, result fields and counters (see table 1). 1102 Match fields are used to match against MPTP packets. Match fields 1103 only consist of path identifier in this document. 1105 Path Identifier: a 32 bit unsigned integer uniquely identifying the 1106 associated relay path. 1108 Result fields include next-hop transport address, idle timeout and 1109 hard timeout. Next-hop transport address is to determine where the 1110 matched packets are forwarded. Idle timeout and hard timeout are used 1111 for relay to actively clear those expired path entries. 1113 Next-hop Transport Address Type: corresponds to the type of the 1114 next-hop transport address. Namely: 1115 1: IPv4 address 1116 2: IPv6 address 1118 Next-hop Transport IP Address: the address to which the relay server 1119 forwards the matched packets. 1121 Next-hop Transport Port: the port number to which the relay server 1122 forwards the matched packets. 1124 Counters are maintained for each path entry and updated for matching 1125 MPTP packets. 1127 Received packets: the amount of packets the path has matched. 1129 Received bytes: the amount of bytes the path has matched. 1131 Duration: the amount of time the path has been installed in the relay 1132 server. 1134 Table 1: Fields in a path entry. 1136 +-------------------------------------+---------------------------+ 1137 | Fields | Bits | 1138 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1139 | Match fields | 1140 +-----------------------------------------------------------------+ 1141 | Path Identifier | 32 | 1142 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1143 | Result fields | 1144 +-----------------------------------------------------------------+ 1145 | Next-hop transport address type | 8 | 1146 +-------------------------------------+---------------------------+ 1147 | | For an IPv6 address, this | 1148 |Next-hop transport IP address | is 128;for an IPv4 address| 1149 | | , this is 32. | 1150 +-------------------------------------+---------------------------+ 1151 | Next-hop transport port | 16 | 1152 +-------------------------------------+---------------------------+ 1153 | Idle timeout | 16 | 1154 +-------------------------------------+---------------------------+ 1155 | Hard timeout | 16 | 1156 +-----------------------------------------------------------------+ 1157 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1158 | Counters | 1159 +-----------------------------------------------------------------+ 1160 | Received packets | 64 | 1161 +-------------------------------------+---------------------------+ 1162 | Received bytes | 64 | 1163 +-------------------------------------+---------------------------+ 1164 | Duration (seconds) | 32 | 1165 +-------------------------------------+---------------------------+ 1166 | Duration (nanoseconds | 32 | 1167 +-----------------------------------------------------------------+ 1169 Path-Table of relay server is managed by relay controller through 1170 Path-Table modification messages. For ADD_PATH requests, relay server 1171 must first check if any path entry with the same path identifier has 1172 existed in the Path-Table. If an overlap conflict exists between an 1173 existing path entry and the ADD_PATH request, relay server must 1174 refuse the addition and respond with a failure response. For valid 1175 ADD_PATH requests, relay server must insert a new path entry in the 1176 Path-Table and respond to the relay controller with a success 1177 response. The counters of received packets and received bytes in the 1178 new inserted entry are set to zero. 1180 For DELETE_PATH requests, if a matching entry exists in the Path- 1181 Table,it must be removed, and a success response is returned to the 1182 relay controller. For DELETE_PATH requests, if no path entry matches, 1183 no path entry modification occurs, and a failure response is returned 1184 to the relay controller. 1186 For UPDATE_PATH requests, if a matching entry exists in the 1187 Path-Table, the result fields of this entry is updated with the value 1188 from the request, and counter fields are left unchanged. For 1189 UPDATE_PATH requests, if no path entry matches, no path entry 1190 modification occurs, and a failure response is returned to the relay 1191 controller. 1193 7.3 Path Validity Management 1195 Each path entry has an idle timeout and a hard timeout associated 1196 with it. These two fields control how quickly a path entry expires. 1197 When a path entry is inserted by an ADD_PATH request or modified by a 1198 UPDATE_PATH request, its idle timeout and hard timeout are set with 1199 the values from the message. 1201 If either value is non-zero, relay server must note the arrival time 1202 of MPTP packet on the associated path, as it may need to evict the 1203 path entry later. A non-zero hard timeout field causes the path entry 1204 to be removed after the given number of seconds, regardless of how 1205 many ackets it has matched. A non-zero idle timeout field causes the 1206 path entry to be removed when it has matched no packets in the given 1207 number of seconds. Using these two fields, relay server can actively 1208 clear those expired path entries. In addition, relay controller may 1209 actively remove path entries by sending DELETE_PATH messages. 1211 If a relay server actively removes a path entry, it must send a 1212 NOTIFY message to relay controller. The NOTIFY message contains a 1213 complete description of the path entry including the reason for 1214 removal, the path entry duration and statistics at the time of 1215 removal. 1217 7.4 Relay Service Management 1219 After successful registration, relay server may send a START message 1220 to relay controller to indicate that it has enough capacity to 1221 provide relay service. 1223 In the case that a relay server is overloaded, or under other some 1224 situations, the relay server may send a STOP message to relay 1225 controller to indicate that it will no longer receive new relay 1226 service requests (i.e. ADD_PATH messages) for a while. During this 1227 period, the relay server still provides relay service for those 1228 existing relay paths. And ECHO messages still need to be sent 1229 periodically between the relay server and the relay controller. 1231 When a relay server recovers from an overloaded state, it may send a 1232 START message to relay controller to indicate that it has additional 1233 capacities to provide new relay services. 1235 When a relay server wants to stop relay service permanently, it 1236 should actively send a BYE message to relay controller before 1237 terminating the connection. In this way, relay controller can be 1238 ready in time to do some remedial measures. For instance, relay 1239 controller may assign new relay paths for the affected media flow. 1241 7.5 MPTP Packet Processing 1243 The main function of a relay server is to provide relay service to 1244 the associated subflows. All subflows associated with a relay server 1245 share a common relay port of this relay server. 1247 After receiving a MPTP packet, relay server extracts the path 1248 identifier from the received MPTP packet and does matching in the 1249 Path-Table. If the received MPTP packet does not match a path entry 1250 in the Path-Table, relay server has nothing to do but to drop the 1251 packet. If the received packet matches a path entry in the 1252 Path-Table, relay server forwards it to the associated next-hop 1253 transport address in the matched path entry. Meanwhile, relay server 1254 updates the associated statistical counters in the matched path 1255 entry. 1257 7.6 Topology Discovery and Performance Measurement 1259 In this document, the term topology refers to the topology that 1260 connects all the relay servers in a MPTS-AR. The relay controller is 1261 responsible for managing the topology of relay overlay network that 1262 is composed of relay servers. The connection between relay servers 1263 can be based on the manual configuration or other mechanism. For 1264 instance, the relay controller can obtain relay network topology 1265 information with the help of the topology discovery process in relay 1266 servers. During the registration process, relay controller may select 1267 several registered relay servers randomly or according to certain 1268 strategy, and insert their information in the corresponding HELLO 1269 success response message. ECHO messages can be used to accomplish the 1270 same function. 1272 After obtaining other relay servers information by manual 1273 configuration or being provisioned by relay controller, relay server 1274 performs topology discovery process. Topology discovery process is 1275 mainly to decide whether there is an overlay link between two relay 1276 servers. An alternative way may be based on the following rules. If 1277 two relay servers are located in the same autonomous domain, there 1278 will be an overlay link connecting the two relay servers. If there is 1279 an inter-domain link between two domains, there is an overlay link 1280 which connects the two relay servers from the two domains. Relay 1281 server should report the result of topology discovery process to 1282 relay controller via ECHO messages periodically. The global overlay 1283 topology is formed in the relay controller based on the distributed 1284 topology observation of relay servers. 1286 An overlay link is usually composed of multiple physical links. 1287 Besides overlay traffic, other nonoverlay traffic would be using the 1288 same physical links. In addition, relay functions provided by relay 1289 server work in application layer, that is, on top of transport layer. 1290 Thus, relay server cannot control or manage the IP-layer resource. 1291 Relay server can only rely on measurement mechanism to obtain the 1292 performance of overlay links associated to it. With performance 1293 measurement, relay server can track dynamically overlay link 1294 capacity. Overlay link capacity can be expressed in terms of the 1295 quality metrics such as loss rate, delay, available bandwidth and so 1296 on. The concrete measurement methods that can be adopted are outside 1297 the scope of this document. 1299 Relay server should report dynamic capacity of overlay links 1300 associated with it to relay controller via ECHO messages 1301 periodically. These capacity information of overlay links will help 1302 the relay controller allocate superior relay paths for user agents. 1304 8. Relay Controller Behavior 1306 Relay controller is responsible for managing relay servers and 1307 selecting one or multiple relay paths for a data flow. 1309 8.1 Relay Server Management 1311 Relay controller manages all relay servers in its region, and 1312 maintains registration and status information of relay servers such 1313 as relay capacity, availability and work load. For each relay server, 1314 relay controller collects its capabilities information by FEATURES 1315 messages, and periodically collects its statistics information by 1316 STATISTICS messages. 1318 8.2 Topology Maintenance 1320 Relay controller manages the topology of a network of relay servers 1321 in its region. Topology information include if an overlay link exists 1322 between any two relay servers and if so, how about the quality of the 1323 overlay link. 1325 Relay controller can obtain topology information in several ways. An 1326 alternative way, as mentioned in section 7.6, is to obtain topology 1327 information from relay servers in its region via ECHO messages. In 1328 another alternative way, relay controller obtains topology 1329 information of relay overlay network itself with underlying network 1330 information. 1332 Many popular overlay applications often generate a huge amount of 1333 cross-ISP traffic overloading links that are frequently subject to 1334 congestion [9]. Besides resulting in a poor experience for the user, 1335 such transits can be quite costly to the network operator. One of the 1336 important reasons is that overlay applications do not have reliable 1337 information of the underlying network topology when selecting overlay 1338 paths. In the IETF, Application-Layer Traffic Optimization (ALTO) 1339 working group has been working on standardization of the ALTO service 1340 [9, 10]. This working group advocates network operators to take the 1341 initiative to provide distributed applications with more reliable 1342 underlying network information, thus achieving performance 1343 optimization of both sides of underlying networks and distributed 1344 applications. In this scenario, relay controller, as an ALTO client, 1345 periodically obtains network maps and cost maps from one or more ALTO 1346 servers. With the reliable network information, relay controller is 1347 enable to organize relay servers into groups in accordance with the 1348 underlying network topology. 1350 8.3 Relay Path Allocation 1352 During establishing a multipath session, the user agent sender or the 1353 signaling server which out-of-band signaling pass through during 1354 session setup, requests relay controller to allocate relay paths by 1355 ALLOCATE_PATH messages. The ALLOCATE_PATH request carries the related 1356 information of the data flow which is going to establish, such as 1357 location information of participants, transport requirements of the 1358 data flow and so on. Relay controller selects one or multiple relay 1359 paths according to the information carried in ALLOCATE_PATH request 1360 and the status information of the registered relay servers. For each 1361 selected relay path, the relay controller sends an ADD_PATH request 1362 to each relay server on the selected relay path. The ADD_PATH request 1363 carries the path identifier, next-hop transport address of the 1364 receiving relay server, etc. A relay path is assigned successfully 1365 only when each relay server on this relay path replies with an 1366 ADD_PATH success response. After successful path allocation, relay 1367 controller replies an ALLOCATE_PATH success response to inform the 1368 user agent sender or the signaling server about the allocated relay 1369 path information including the path identifier, user agent sender's 1370 next-hop transport address, etc. 1372 How relay controller selects superior candidate relay paths for an 1373 oncoming transmission session between user agents is critical. If the 1374 assigned relay path has poor performance, MPTS-AR will not reach the 1375 potential of multipath transport, and also may get even worse 1376 performance than single-path transmission case of the default IP 1377 path. How to select superior relay paths is outside the scope of this 1378 document. An ideal approach for selecting relay paths should take 1379 into account both underlying network topology and transport 1380 requirements of upper applications. 1382 9. OpenPath Protocol 1384 9.1 Protocol Overview 1386 OpenPath is based on a request/response transaction model. Each 1387 transaction consists of a request and a response. A response uses the 1388 same transaction id as is in the associated request to facilitate 1389 pairing. The transaction id is a 32-bit identifier generated by the 1390 request sender. 1392 OpenPath messages are guaranteed delivery over a connection-oriented 1393 channel. All integer fields are carried in network octet order, that 1394 is, most significant byte first. Octets designated as padding have 1395 the value zero. 1397 All OpenPath messages begin with an OpenPath common header. OpenPath 1398 messages MAY contain a message body. The structure and interpretation 1399 of a body depends on the message type. 1401 OpenPath message types fall into four classes: relay-to-controller, 1402 controller-to-relay, user agent-to-controller and symmetric. 1404 Relay-to-controller messages are initiated by relay server and used 1405 to manage the channel connection and update relay controller of 1406 changes to the relay server. Controller-to-relay messages are 1407 initiated by relay controller and used to manage the Path-Table or 1408 inspect the state of relay servers. User agent-to-controller messages 1409 are initiated by user agent or out-of-band signaling server, and used 1410 for relay path allocation. Symmetric messages are initiated by either 1411 relay controller or relay server and used to keep alive the channel 1412 connection and topology maintenance. 1414 9.1.1 Relay-to-Controller 1416 Relay-to-controller message is initiated by a relay server and 1417 requires a response message from relay controller. 1419 HELLO: Relay server registers with relay controller by sending a 1420 HELLO request. Relay controller must respond with a HELLO response 1421 that indicates the outcome of registration. This is commonly 1422 performed upon establishment of the OpenPath connection channel. 1424 The relay server identifier field is set to zero in the initial HELLO 1425 request. Relay controller must assign a unique identifier for this 1426 relay server and insert the assigned relay server identifier in the 1427 corresponding HELLO response. Subsequent HELLO requests may carry the 1428 assigned relay server identifier directly. 1430 The HELLO request contains a message body. The body contains the IP 1431 address and port of relay server for the relay service. 1433 The HELLO success response may contains a message body. The body 1434 contains the information of one or more other registered relay 1435 servers. The information of a relay server here include the IP 1436 address for relay service and the relay server identifier. 1438 START: Relay server starts relay service by sending a START request. 1439 Relay controller must respond with a START response that indicates 1440 the outcome of relay service startup. 1442 STOP: Relay server may stop relay service temporarily by sending a 1443 STOP request. For instance, when a relay server is overloaded, it may 1444 want to refuse accepting any new relay service requests for a while. 1445 Relay controller must respond with a STOP response that indicates the 1446 outcome of relay service pause. During relay service pause, this 1447 relay server still provides relay service for those existing relay 1448 paths. This relay server may restart relay service by sending a START 1449 request after a while. 1451 BYE: Relay server may terminate the relay service permanently by 1452 sending a BYE request, such as before terminating the OpenPath 1453 connection channel or exiting. Meanwhile, this relay server ceases 1454 relay service for all existing relay paths. If this relay server 1455 wants to start relay service again, it must first perform 1456 registration with relay controller. 1458 NOTIFY: When a relay server actively removes a path entry, it may 1459 notify relay controller by sending a NOTIFY request. For instance, in 1460 order to save the resource, relay server actively removes those path 1461 entries which lack activity. 1463 9.1.2 Controller-to-Relay 1465 Controller-to-relay message is initiated by a relay controller and 1466 require a response message from relay server. 1468 FEATURES: Relay controller may request the capabilities of a relay 1469 server by sending a FEATURES request. This relay server must respond 1470 with a FEATURES response that specifies its capabilities. This is 1471 commonly performed after successful registration of this relay 1472 server. 1474 STATISTICS: Relay controller may periodically collect statistics from 1475 relay servers by sending STATISTICS requests. Relay server must 1476 respond with a STATISTICS response that specifies its current 1477 statistics. 1479 ADD_PATH: When relay controller assigns relay paths for a data flow, 1480 it must send an ADD_PATH request to each relay server on the assigned 1481 relay path. The relay server must respond with an ADD_PATH response 1482 that specifies the outcome of adding a new path entry. A relay path 1483 is assigned successfully only when each relay server replies with an 1484 ADD_PATH success response. 1486 UPDATE_PATH: Relay controller may want to modify an existing path 1487 entry in the Path-Table of a relay server by sending a UPDATE_PATH 1488 request. For instance, a data flow may be "put on hold" and data 1489 transmission may be ceased for a while. In this case, relay 1490 controller may update the idle timeout and hard timeout of the 1491 corresponding path entries of all the relay servers on the affected 1492 relay paths to a longer time. Relay server must respond with an 1493 UPDATE_PATH response that specifies the outcome of updating an 1494 existing path entry. 1496 DELETE_PATH: Relay controller may delete an existing path entry in 1497 the Path-Table of a relay server by sending a DELETE_PATH request, 1498 such as when a data flow ends normally. Relay server must respond 1499 with a DELETE_PATH response that specifies the outcome of deleting an 1500 existing path entry. 1502 9.1.3 User agent-to-Controller 1504 User agent-to-controller message is initiated by a user agent or an 1505 out-of-band signaling server, and requires a response message from 1506 relay controller. 1508 ALLOCATE_PATH: During establishing or the process of a multipath 1509 session, user agent sender may request relay controller to allocate 1510 candidate relay paths for one or multiple media flows in a session 1511 by exchanging ALLOCATE_PATH messages directly with relay controller. 1512 Or the signaling server requests relay controller to allocate 1513 candidate relay paths for user agents, and inserts the information of 1514 the allocated relay paths into corresponding signaling messages to 1515 inform user agents. Relay controller must respond with an 1516 ALLOCATE_PATH response that specifies the outcome of path allocation 1517 and the information of the assigned relay path if exists. 1519 RELEASE_PATH: Before tearing down a multipath session, user agent 1520 sender may request relay controller to release the relay paths 1521 assigned for the multipath session by exchanging RELEASE_PATH 1522 messages directly with relay controller. RELEASE_PATH request message 1523 carries the session identifier information. Or during the process of 1524 a multipath session, user agent may request relay controller to 1525 release the relay paths assigned for one or multiple specified media 1526 flow. RELEASE_PATH request message carries the information of one or 1527 more relay path identifiers. Alternatively, the signaling server 1528 requests relay controller to release the assigned relay paths on 1529 behalf of the user agent sender. Relay controller must respond with 1530 an RELEASE_PATH response that specifies the outcome of deleting relay 1531 paths. 1533 9.1.4 Symmetric 1535 Symmetric message is sent in either direction between relay server 1536 and relay controller. 1538 ECHO: ECHO requests MUST be sent periodically from either relay 1539 controller or relay server. ECHO messages can be used to measure the 1540 latency of the connection between relay controller and relay server, 1541 as well as verify the peer's liveness. The receiver of an ECHO 1542 request must respond with an ECHO response. 1544 Relay server can insert the information of topology and overlay link 1545 capacity in ECHO requests or ECHO responses. 1547 9.2 Common Structures 1549 This section describes several common structures used by multiple 1550 messages. 1552 9.2.1 OpenPath Common Header 1554 All OpenPath messages begin with an OpenPath common header which is 1555 defined below: 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | V |R|S| Type | Length | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Peer Identifier | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Transaction Identifier | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 Version (V): 6 bits 1568 This field identifies the version of OpenPath protocol version being 1569 used. The version defined by this document is one (1). 1571 R: 1 bit 1572 If the R bit is set, the message is an OpenPath request; otherwise, 1573 the message is an OpenPath response. 1575 S: 1 bit 1576 When the message is a request, this bit is reserved. When the message 1577 is a response, if the S bit is set, the message is a success 1578 response; otherwise, the message is a failure response. 1580 Type: 8 bits 1581 This field identifies the type of the OpenPath messages. This 1582 document defines 13 OpenPath message types: 1584 +----------------------------------------------------------------+ 1585 | Type Value | Type Name | Sending Direction | 1586 +--------------+---------------+---------------------------------+ 1587 | 1 | HELLO | Relay -> Controller | 1588 +--------------+---------------+---------------------------------+ 1589 | 2 | BYE | Relay -> Controller | 1590 +--------------+---------------+---------------------------------+ 1591 | 3 | ECHO | Relay -> Controller Or | 1592 | | | Controller -> Relay | 1593 +--------------+---------------+---------------------------------+ 1594 | 4 | START | Relay -> Controller | 1595 +--------------+---------------+---------------------------------+ 1596 | 5 | STOP | Relay -> Controller | 1597 +--------------+---------------+---------------------------------+ 1598 | 6 | NOTIFY | Relay -> Controller | 1599 +--------------+---------------+---------------------------------+ 1600 | 7 | FEATURES | Controller -> Relay | 1601 +--------------+---------------+---------------------------------+ 1602 | 8 | STATISTICS | Controller -> Relay | 1603 +--------------+---------------+---------------------------------+ 1604 | 9 | ADD_PATH | Controller -> Relay | 1605 +--------------+---------------+---------------------------------+ 1606 | 10 | DETELE_PATH | Controller -> Relay | 1607 +--------------+---------------+---------------------------------+ 1608 | 11 | UPDATE_PATH | Controller -> Relay | 1609 +----------------------------------------------------------------+ 1610 | 12 | ALLOCATE_PATH | User Agent -> Controller | 1611 +--------------+---------------+---------------------------------+ 1612 | 13 | RELEASE_PATH | User Agent -> Controller | 1613 +----------------------------------------------------------------+ 1615 Length: 16 bits 1616 The length field indicates the total length of the message in 32-bit 1617 words including the header and any padding. 1619 Peer Identifier: 32 bits 1620 This field is a 32-bit identifier that corresponds to a globally 1621 unique relay server, user agent or out-of-band signaling server. It 1622 is generated by relay controller during registration process of a 1623 relay server, user agent or out-of-band signaling server. This 1624 identifier remains unchanged during the entire lifecycle of the 1625 OpenPath connection with relay controller. For OpenPath messages 1626 exchanged between relay controller and relay server, this field 1627 corresponds to a relay server identifier. For OpenPath messages 1628 exchanged between relay controller and user agent, this field 1629 corresponds to a user agent identifier. For OpenPath messages 1630 exchanged between relay controller and out-of-band signaling server, 1631 this field corresponds to a signaling server identifier. For the last 1632 two cases, it is uniformly called user agent identifier. 1634 Transaction Identifier: 32 bits 1635 This field identifies the transaction id associated with this 1636 message. It is randomly generated by the request sender and discarded 1637 when the associated response message is received. The transaction 1638 identifier of a response message must always match the requests that 1639 prompted them. 1641 9.2.2 Common Body of OpenPath Failure Responses 1643 OpenPath failure responses of all message types MAY contain an 1644 optional body after the OpenPath common header. If present, the body 1645 conforms to a common structure defined below. 1647 0 1 2 3 1648 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 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | Status code | Rlength | reason | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | reason | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 Status code: 8 bits 1656 This field is a numeric result code that indicates the outcome of a 1657 request processing. 1659 Rlength: 8 bits 1660 This field is the length of the reason phrase in 16-bit word length. 1662 Reason: variable size 1663 This field is a short textual description of the status code. 1665 9.2.3 Transport Address Structure 1667 Relay server needs to advertise relay controller about its transport 1668 address for relay service. Relay controller also needs to tell relay 1669 server about the transport address of its next-hop node for each 1670 associated path. A transport address is defined as follow. 1672 0 1 2 3 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Address Type | Pad(0) | Port | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Address | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Address Type: 8 bits 1681 This field is the type of transport address. Namely: 1682 1: IPv4 address 1683 2: IPv6 address 1685 Port: 16 bits 1686 This field is the port number part of transport address. 1688 Address: 4 octets (IPv4), 16 octets (IPv6) 1689 The IP address part of transport address. 1691 9.3 Message Format of OpenPath Request and Success Response 1693 9.3.1 HELLO 1695 A HELLO request contains a body beyond an OpenPath common header. 1697 The body contains the transport address of the relay server to 1698 provide relay service. 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | V |R|S| Type | Length | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Relay Server Identifier | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Transaction Identifier | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Address Type | Pad(0) | Port | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Address | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 A HELLO success response may contains a message body. The body 1714 contains information of one or more other registered relay servers. 1715 The information of a relay server here include the address for relay 1716 service and the relay server identifier. 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Other Relay Server Identifier | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Address Type | Pad(0) | Port | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | IP Address of Other Relay Server | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 An example of A HELLO success response is: 1728 0 1 2 3 1729 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 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | V |0|1| 1 | Length | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Relay Server Identifier | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Transaction Identifier | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | Identifier of Other Relay Server | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | Address Type | Pad(0) | Port | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | IP Address of Other Relay Server | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | ...... | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 9.3.2 START/STOP/BYE 1748 START/STOP/BYE requests and their success responses have no body; 1749 that is, they only contain an OpenPath common header. 1751 9.3.3 ECHO 1753 An ECHO request consists of an OpenPath common header and an optional 1754 body. If the body is absent, an ECHO transaction is used to simply 1755 verify liveness between relay controller and relay server. If the 1756 body is present, it may contain a timestamp field to check latency 1757 between relay controller and relay server. Example: 1759 0 1 2 3 1760 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 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | V |R|S| Type | Length | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Relay Server Identifier | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Transaction Identifier | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | NTP timestamp, most significant word | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | NTP timestamp,least significant word | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 NTP timestamp: Using the timestamp format of the Network Time 1774 Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1775 1900 [2]. The full resolution NTP timestamp is a 64-bit unsigned 1776 fixed-point number with the integer part in the first 32 bits and the 1777 fractional part in the last 32 bits. 1779 If the body of an ECHO request only contain a timestamp field, its 1780 response has the same message format as the associated ECHO request. 1782 An ECHO message (request message or response message) generated by a 1783 relay server may contain the information of one or more overlay link 1784 capacities in its body. 1786 0 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | V |R|S| Type | Length | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Relay Server Identifier | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Transaction Identifier | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Identifier of Neighboring Relay Server | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Link Type | Packet Loss Rate | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Transport Delay | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Transport Bandwidth | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 Identifier of Neighboring Relay Server: 1805 the identifier of the relay server which is connected to this ECHO 1806 message sender by a overlay link. 1808 Link Type: 16 bits 1809 This field identifies the type of the overlay link between this ECHO 1810 message sender and the relay server which is identified by the 1811 identifier of neighboring relay server field. This document defines 2 1812 overlay link types: 1814 +-----------------------------------------------------------------+ 1815 | Type Value | Description | 1816 +--------------+--------------------------------------------------+ 1817 | 1 |The two relay servers which are associated with | 1818 | |the overlay link are located in the same | 1819 | |autonomous domain. | 1820 +--------------+--------------------------------------------------+ 1821 | 2 |The two relay servers which are associated with | 1822 | |the overlay link are from two different autonomous| 1823 | |domains. And there is an interdomain link between | 1824 | |these two domains. | 1825 +--------------+--------------------------------------------------+ 1827 Packet Loss Rate: 16 bits 1828 This field indicates the estimated packet loss rate of the overlay 1829 link since the last ECHO message which contains the information 1830 report of the same overlay link. This field is expressed in units of 1831 per thousand. 1833 Transport Delay: 32 bits 1834 This field indicates the estimated unidirectional transport delay of 1835 the overlay link from this ECHO message sender to the relay server 1836 which is identified by the identifier of neighboring relay server 1837 field. This field is expressed in units of 1/65536 seconds. 1839 Transport Bandwidth: 32 bits 1840 This field indicates the estimated transport bandwidth of the overlay 1841 link. This field is expressed in units of kilo-bits per second 1842 (kpbs). 1844 9.3.4 NOTIFY/DELETE_PATH 1846 NOTIFY/DELETE_PATH requests contain a body beyond an OpenPath common 1847 header. The body only contains a path identifier field. 1849 0 1 2 3 1850 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 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | V |R|S| Type | Length | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | Relay Server Identifier | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Transaction Identifier | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Path Identifier | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Path Identifier: 32 bits 1862 This field is a 32-bit identifier that corresponds to a globally 1863 unique path. It is generated by relay controller when assigning relay 1864 paths for a data flow. 1866 NOTIFY/DELETE_PATH success responses only contain an OpenPath common 1867 header. 1869 9.3.5 ADD_PATH/UPDATE_PATH 1871 ADD_PATH/UPDATE_PATH requests contain a body beyond an OpenPath 1872 common header. The body contains match fields and result fields of a 1873 path entry. The match fields contain a single path identifier field. 1874 The result fields contain next-hop transport address and idle/hard 1875 timeout fields. 1877 0 1 2 3 1878 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 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | V |R|S| Type | Length | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Relay Server Identifier | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Transaction Identifier | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Path Identifier | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | Address Type | Pad(0) | Port | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Address | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Idle timeout | Hard timeout | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 Idle timeout: 16 bits 1896 This field is the number of seconds after which the path will timeout 1897 if no traffic. 1899 Hard timeout: 16 bits 1900 This field is the number of seconds after which the path must expire 1901 regardless of whether or not packets go through the path. 1903 ADD_PATH/UPDATE_PATH success responses only contain an OpenPath 1904 common header. 1906 9.3.6 ALLOCATE_PATH 1908 In a multimedia session, there may be more than one media flow that 1909 need multipath transport, and a media flow could be unidirectional or 1910 bidirectional. Relay path requesters can request relay controller to 1911 allocate relay paths for all unidirectional media flows in a 1912 multimedia session at once. 1914 ALLOCATE_PATH requests contain a body beyond an OpenPath common 1915 header. The body contains information of the multimedia session, 1916 which is going to be established, and one or more data flows in this 1917 session. Information of a media flow include flow identifier, two 1918 communicating endpoint addresses, and the transport requirements. 1920 0 1 2 3 1921 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 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | V |R|S| Type | Length | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | User Agent Identifier | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Transaction Identifier | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 |Sess.ID. Length| | 1930 +-+-+-+-+-+-+-+-+ Session Identifier | 1931 | | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | P1.Addr. Type | DT| Flow ID | P1's Port | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | P1's Address | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | P2.Addr. Type | PUM | AMT | P2's Port | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | P2's Address | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | Required Transport Bandwidth | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | Maximum End-to-end Transport Delay | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Another data flow's information | 1946 | ... | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 Sess.ID. Length: 8 bits 1951 The length field indicates the total length of the following Session 1952 Identifier in bytes. 1954 Session Identifier: variable size 1956 This field indicates the unique identifier of the ongoing multipath 1957 session. If its length is not (4*k-1) bytes, one or more additional 1958 padding octets which are not part of the session identifier should be 1959 appended at the end. 1961 P1 & P2: P1 and P2 represent two communicating endpoints of the 1962 ongoing multipath session. 1964 DT: 2 bits 1966 This field indicates the direction of the corresponding data flow. If 1967 the binary value of this field is '10', the data flow is 1968 unidirectional, and P1 and P2 are source side and destination side of 1969 this flow respectively. If the binary value of this field is '01', 1970 the data flow is unidirectional, and P1 and P2 are destination side 1971 and source side of this flow respectively. If the binary value of 1972 this field is '11', the data flow is bidirectional, and will be 1973 regarded as two independent unidirectional flows in opposite 1974 directions, that is, their 'DT' are '10' and '01' respectively. 1976 Flow ID: 6 bits 1978 This field indicates the identifier of the corresponding data flow. 1979 The identifer of a flow MUST be unique in the scope of the multipath 1980 session. 1982 Path Usage Method (PUM): 4 bits 1984 This field indicates how to use multiple paths, concurrently, 1985 redundantly, or by other ways. This document defines two usage 1986 methods of multiple paths: UM = 1, indicates concurrent-mode; UM = 2, 1987 indicates redundant-mode. 1989 Application-specific MPTP type (AMT): 4 bits 1991 This field identifies the type of application-specific MPTP that 1992 packet format of this data flow conforms to. This document defines 1993 two application-specific MPTP types: AMT = 1, indicates that this 1994 MPTP packet conforms to RTP-based multimedia application-specific 1995 MPTP; AMT = 2, indicates that this MPTP packet conforms to reliable 1996 application-specific MPTP. 1998 Required Transport Bandwidth: 32 bits 2000 This field indicates the required transport bandwidth of the data 2001 flow which is going to be established. If the data flow is 2002 bidirectional, this field indicates the required bandwidth of the 2003 corresponding unidirectional flow. This field is expressed in units 2004 of kilo-bits per second (kpbs). 2006 Maximum End-to-end Transport Delay: 32 bits 2008 This field indicates the maximum end-to-end transport relay that 2009 could be tolerated by the data flow which is going to be established. 2010 This field is expressed in units of millisecond (ms). 2012 An ALLOCATE_PATH success response contains a body beyond an OpenPath 2013 common header. The body contains information of the multimedia 2014 session and one or more allocated relay path including the path 2015 identifier and user agent sender's next-hop transport address. 2017 0 1 2 3 2018 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 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | V |R|S| Type | Length | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | User Agent Identifier | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Transaction Identifier | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 |Sess.ID. Length| | 2027 +-+-+-+-+-+-+-+-+ Session Identifier | 2028 | | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | DT| Flow ID | Pad(0) | the number of relay paths | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Path Identifier | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Address Type |Path Group ID. | Port | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Address | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | the next path's information | 2039 | ...... | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 Path Group ID. : 8 bits 2044 The allocated relay paths are divided into groups, each of which 2045 could meet the required transport bandwidth of the data flow stated 2046 in the corresponding ALLOCATE_PATH request. This field indicates the 2047 identifier of the path group that this relay path belongs to. 2049 9.3.7 RELEASE_PATH 2051 RELEASE_PATH requests contain a body beyond an OpenPath common 2052 header. The body contains the session identifier and optionally one 2053 or more path identifier fields. Each path identifier corresponds to 2054 one relay path which is being requested to be released. 2056 0 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | V |R|S| Type | Length | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | User Agent Identifier | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Transaction Identifier | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 |Sess.ID. Length| | 2066 +-+-+-+-+-+-+-+-+ Session Identifier | 2067 | | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Path Identifier | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | ...... | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 RELEASE_PATH success responses only contain an OpenPath common 2075 header. 2077 9.3.8 FEATURES 2079 A FEATURES request only contains an OpenPath common header. 2081 A FEATURES success response contains a body beyond an OpenPath common 2082 header. 2084 (to be continued) 2086 9.3.9 STATISTICS 2088 A STATISTICS request only contains an OpenPath common header. 2090 A STATISTICS success response contains a body beyond an OpenPath 2091 common header. 2093 (to be continued) 2095 10. MPTP Profile 2097 10.1 Overview 2099 As stated in Section 5, MPTP obtain a simple, unreliable datagram 2100 service from the underlying UDP. MPTP SHOULD meet various delivery 2101 requirements of upper applications. As stated in the introduction, in 2102 order to be extensible and suitable for various applications, MPTP is 2103 designed to be a protocol suite which consists of one MPTP profile 2104 and multiple application-specific MPTPs. The MPTP profile only 2105 defines common rules of multipath transport based on 2106 application-level relay for various upper applications. It is aimed 2107 to provide application-level multipath routing mechanism. Other 2108 transmission requirements of upper applications, such as timely or 2109 reliable delivery, SHOULD be met in corresponding 2110 application-specific MPTP documents. 2112 In addition to carrying payload data passed from upper application 2113 programs through multiple paths, MPTP also need to provide path 2114 control functions including keeping path alive and monitoring the 2115 quality of data delivery on each path. Therefore, MPTP packets are 2116 divided into two types: MPTP data packets and MPTP control packets. 2117 MPTP control packets include MPTP keep-alive packets and MPTP report 2118 packets. 2120 User agent sender formats the payload data passed from upper 2121 application programs into MPTP data packets which are sent along the 2122 associated path. 2124 User agent sender SHOULD send MPTP keep-alive packets periodically 2125 for each path including both active path and non-active path. 2127 To monitor the transport quality of a path, user agents generate MPTP 2128 report packets for each subflow. Due to the content of MPTP report 2129 packets depends on the delivery requirements of upper application 2130 programs, this document does not give concrete content and processing 2131 of the MPTP report packets, which should be described in 2132 application-specific MPTP documents. Here, we only outline the 2133 delivery methods of MPTP report packets. The user agent sender 2134 generates MPTP subflow sender reports for each subflow and sends them 2135 along the same path as the subflow MPTP data packets. The user agent 2136 receiver responds with MPTP subflow receiver reports which are sent 2137 along the default path. 2139 To evaluate the integrated efficiency of multipath transport and 2140 dynamically adjust sender-side schedule policy, the user agent 2141 receiver generates MPTP flow recombination reports and sends them to 2142 sender along the default path. 2144 According to the delivery requirements of upper applications, the 2145 user agent receiver optionally generates MPTP flow recombination 2146 reports, which should also be described in application-specific MPTP 2147 documents. 2149 10.2 MPTP Fixed Header Fields 2151 10.2.1 Fixed Header Fields of MPTP Data Packet 2152 All MPTP data packets have a fixed twelve octet-length header, which 2153 is defined below: 2155 0 1 2 3 2156 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 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 |V=1|T|P| AMT | TOS | Rsvd | SSSN | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Path Identifier | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Flow Sequence Number | 2163 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2164 | | 2165 | Payload Data | 2166 | | 2167 | .... | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 The fields have the following meaning: 2172 version (V): 2 bits 2173 This field identifies the version of MPTP. The version defined by 2174 this document is one (1). 2176 MPTP packet type (T): 1 bit 2177 This field identifies the type of a MPTP packet. If the MPTP packet 2178 type bit is set, this packet is a MPTP data packet; otherwise, this 2179 packet is a MPTP control packet. 2181 padding (P): 1 bit 2182 If the padding bit is set, the packet contains one or more additional 2183 padding octets at the end which are not part of the payload. The last 2184 octet of the padding contains a count of how many padding octets 2185 should be ignored, including itself. Padding may be needed by some 2186 encryption algorithms with fixed block sizes. 2188 Application-specific MPTP type (AMT): 4 bits 2189 This field identifies the type of application-specific MPTP that this 2190 packet format conforms to. It is identical as the same named 2191 attribute in ALLOCATE_PATH message in Section 9.3.6. 2193 type of service (TOS): 4 bits 2194 This field, similar to TOS field in internet packet header, is 2195 specified along the abstract parameters precedence, delay, 2196 throughput, and reliability. These abstract parameters embody the 2197 delivery requirements of upper application programs. The values of 2198 these abstract parameters should be specified in application-specific 2199 MPTP documents. 2201 Precedence: An independent measure of the importance of the 2202 payload data. 2204 Delay: Prompt delivery is important for the payload data with 2205 this indication. 2207 Throughput: High data rate is important for the payload data with 2208 this indication. 2210 Reliability: A higher level of effort to ensure delivery is 2211 important for the payload data with this indication. 2213 Rsvd: 4 bits 2214 These 4 bits are reserved, which can be used and described in 2215 application-specific MPTP documents. 2217 Subflow-Specific Sequence Number (SSSN): 16 bits 2218 This field is the sequence of the MPTP data packet in the subflow. 2219 Each subflow has its own strictly monotonically increasing sequence 2220 number space. 2222 Path Identifier: 32 bits 2223 This field is the identifier of the path that the MPTP packet is 2224 associated with. For a relay path, the path identifier is globally 2225 unique; for the default path, the path identifier is fixed to zero. 2227 Flow Sequence Number (FSN): 32 bits 2228 This field is the sequence of the MPTP data packet in the original 2229 flow. The original flow has the unique strictly monotonically 2230 increasing sequence number space. 2232 Payload Data: variable size 2233 The content of payload data should be described in 2234 application-specific MPTP documents. 2236 10.2.2 Fixed Header Fields of MPTP Control Packet 2238 MPTP control packets except MPTP flow recombination report packets 2239 have a fixed eight octet-length header, which is defined below. In 2240 comparison, MPTP flow recombination report packets have no path 2241 identifier field. 2243 0 1 2 3 2244 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 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 |V=1|T|P| AMT | CT | Length | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Path Identifier | 2249 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2250 | | 2251 | Control Data | 2252 | | 2253 | .... | 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 The fields of V, T, P, AMT and Path Identifier have the same meaning 2257 as those fields in MPTP data packet. Other fields have the following 2258 meaning: 2260 MPTP control packet type (CT): 8 bits 2262 This field identifies the type of MPTP control packet. Namely: 2264 +-------------------------------------------------------------------+ 2265 |MPTP control packet type (CT) |Use | 2266 +---------------------------------+---------------------------------+ 2267 |1 |Subflow Sender Report, for | 2268 | |transmission statistics from the | 2269 | |user agent sender | 2270 +---------------------------------+---------------------------------+ 2271 |2 |Subflow Receiver Report, for | 2272 | |reception statistics from the | 2273 | |user agent receiver | 2274 +---------------------------------+---------------------------------+ 2275 |3 |Keep Alive, for keeping a path | 2276 | |alive | 2277 +-------------------------------------------------------------------+ 2278 |4 |Flow Recombination Report, for | 2279 | |flow recombination statistics | 2280 | |from the user agent receiver | 2281 +-------------------------------------------------------------------+ 2283 Length: 16 bits 2284 This field is the length of the encapsulated control data after the 2285 MPTP fixed header in byte length. 2287 Control Data: variable size 2288 For MPTP keep-alive packet, control data may be empty. 2289 For MPTP report packet, the content of control data should be 2290 described in application-specific MPTP documents. 2292 11. SDP Considerations 2294 The advertisement of MPTP capability and relay paths MUST be 2295 performed by out-of-band signaling, for example, as part of a SIP 2296 offer/answer exchange using SDP. This section defines dedicated 2297 extensions in SDP. SDP syntax and procedures are available that can 2298 be re-used or easily adapted to provide the necessary capabilities. 2300 11.1 Signaling MPTP Capability in SDP 2302 A communication participant, who follows the framework of multipath 2303 transport system based on application-level relay, MUST use SDP to 2304 indicate that it supports and wants to use this framework. The 2305 mptp-relay attribute defined here will be used to indicate the 2306 support for this framework. The mptp-relay attribute is a media level 2307 parameter. The syntax of the mptp-relay attribute is defined using 2308 the following Augmented BNF, as defined in [RFC5234]. 2310 mptp-relay-attrib = "a=" "mptp-relay" ":" mptp-name CRLF 2312 The mptp-name field indicates an application-specific MPTP. In an 2313 application-specific MPTP document, the value of mptp-name field MUST 2314 be given for that application-specific MPTP. 2316 When SDP is used following the offer/answer mode [RFC3264], the 2317 "mptp-relay" attribute indicates the desire to transport media flow 2318 on multiple paths. If the offerer supports and wishes to use MPTP, 2319 it MUST include a media-level "a=mptp-relay" attribution in the 2320 initial SDP offer. If the initial SDP offer contains "a=mptp-relay" 2321 attribution and if the answerer supports and wishes to use MPTP, it 2322 MUST include this attribute in the SDP answer. 2324 When SDP is used in a declarative manner, the "mptp-relay" attribute 2325 indicates that the message sender can send or receive media data over 2326 multiple paths. The message receiver SHOULD be capable to stream 2327 media to multiple paths or be prepared to receive media from multiple 2328 paths. 2330 11.2 Relay Path Advertisement in SDP 2332 The information of candidate relay paths MUST be advertised to the 2333 user agent sender in the out-of-band signaling. The relay-path 2334 attribute is extended to advertise candidate relay paths in SDP. The 2335 syntax of the relay-path attribute is defined using the following 2336 Augmented BNF, as defined in [RFC5234]. The definitions of DIGIT, SP 2337 and CRLF are according to RFC4234. 2339 relay-path-attrib = "a=" relay-path-label ":" counter SP path-id SP 2340 transport-address CRLF 2341 relay-path-label = "relay-path" 2342 counter = 1*DIGIT 2343 path-id = 8*8HEXDIG 2344 transport-address = addrtype "/" unicast-address "/" port 2345 ; addrtype from RFC4566, typically "IP4" | "IP6" 2346 ; port from RFC4566 2347 unicast-address = IP4-address / IP6-address 2348 ; IP4-address from RFC4566 2349 ; IP6-address from RFC4566 2351 The path identifier and the next-hop transport address of the user 2352 agent sender for each candidate relay path is encapsulated in a 2353 relay-path attribute. 2355 The parameter indicates the priority of the associated 2356 relay path and it is a monotonically increasing positive integer 2357 starting at 1. Number 1 is the highest priority. The counter must be 2358 reset for each media line. The relay-path attributes are ordered 2359 based on a decreasing priority level. 2361 The parameter indicates the path identifier of the 2362 associated relay path. 2364 The is the next-hop transport address of the 2365 user agent sender for associated candidate relay path. The 2366 is the address type. This document only defines IP4 and IP6 for IPv4 2367 addresses and IPv6 addresses respectively. 2369 As recommended in [11] and [12], this document uses IPV6 addresses 2370 in the following example: 2372 a=relay-path:1 0x1a3b6c9d IP6/2001:db8:a0b:103::1/10000 2374 12. IANA Considerations 2376 The following contact information shall be used for all registrations 2377 in this document: 2379 Contact: Weimin Lei 2380 mailto:leiweimin@ise.neu.edu.cn 2381 tel:+86-24-8368-3048 2383 Note to the RFC-Editor: When publishing this document as an RFC, 2384 please replace "RFC XXXX" with the actual RFC number of this document 2385 and delete this sentence. 2387 12.1 SDP Attributes 2388 In the registry for SDP parameters, the attributes named "mptp-relay" 2389 and "relay-path" have been registered as follows: 2391 SDP Attribute ("att-field"): 2393 Attribute Name: mptp-relay 2394 Long form: Multipath transport system framework based on 2395 application-level relay 2396 Type of name: att-field 2397 Type of attribute: Media level only 2398 Subject to charset: No 2399 Purpose: This attribute is used to indicate support for 2400 multipath transport system framework based on 2401 application-level relay. 2402 Reference: See this document 2403 Values: See this document. 2405 SDP Attribute ("att-field"): 2407 Attribute Name: relay-path 2408 Long form: Relay Path of multipath transport system 2409 framework based on application-level relay 2410 Type of name: att-field 2411 Type of attribute: Media level only 2412 Subject to charset: No 2413 Purpose: This attribute is used to describe the 2414 information of a relay path including the path 2415 identifier and the next-hop transport address 2416 of the user agent sender. 2417 Reference: See this document 2418 Values: See this document. 2420 13. Security Considerations 2422 TBD 2424 14. References 2426 14.1 Normative References 2428 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2429 Levels", BCP 14, RFC 2119, March 1997. 2431 [2] Mills, D., "Network Time Protocol (Version 3) Specification, 2432 Implementation and Analysis", RFC 1305, March 1992. 2434 14.2 Informative References 2436 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2437 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2438 RFC 3550, July 2003. 2440 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2441 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2442 Session Initiation Protocol", RFC 3261, June 2002. 2444 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2445 Description Protocol", RFC 4566, July 2006. 2447 [6] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming 2448 Protocol (RTSP)", RFC2326, April 1998. 2450 [7] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, 2451 "Architectural Guidelines for Multipath TCP Development", 2452 RFC6182, March 2011. 2454 [8] Stewart, R., "Stream Control Transmission Protocol", RFC4960, 2455 September 2007. 2457 [9] Seedorf, J., and E. Burger, "Application-Layer Traffic 2458 Optimization (ALTO) Problem Statement", RFC5693, October 2009. 2460 [10] Alimi, R., Penno, R., et al. "Application-Layer Traffic 2461 Optimization (ALTO) Protocol", RFC7285, September 2014. 2463 [11] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2464 Reserved for Documentation", RFC3849, July 2004. 2466 [12] Robachevsky, A., "Mandating use of IPv6 in examples", 2467 draft-robachevsky-mandating-use-of-ipv6-examples-01 (work in 2468 progress), April 2016. 2470 Authors' Addresses 2472 Weimin Lei 2473 Northeastern University 2474 Department of Communication and Electronic Engineering 2475 College of Computer Science and Engineering 2476 Shenyang, China, 110819 2477 P. R. China 2479 Phone: +86-24-8368-3048 2480 Email: leiweimin@mail.neu.edu.cn 2482 Wei Zhang 2483 Northeastern University 2484 Department of Communication and Electronic Engineering 2485 College of Computer Science and Engineering 2486 Shenyang, China, 110819 2487 P. R. China 2489 Email: zhangwei1@mail.neu.edu.cn 2491 Shaowei Liu 2492 Northeastern University 2493 Department of Communication and Electronic Engineering 2494 College of Computer Science and Engineering 2495 Shenyang, China, 110819 2496 P. R. China 2498 Email: liushaowei.ise.neu@gmail.com 2499 liu_nongfu@163.com