idnits 2.17.1 draft-braden-2level-signal-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 125 has weird spacing: '...hat are used ...' == Line 164 has weird spacing: '...d allow the t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2002) is 7844 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2961' is mentioned on line 117, but not defined == Missing Reference: 'ISint93' is mentioned on line 137, but not defined == Missing Reference: 'OIf' is mentioned on line 918, but not defined == Missing Reference: 'RFC1191' is mentioned on line 1129, but not defined == Unused Reference: 'CM01' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'ISInt93' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'ISrsvp96' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'XSong02' is defined on line 1257, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AIF01' -- Possible downref: Non-RFC (?) normative reference: ref. 'Integrity00' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'PCQoS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'Refresh00' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIST02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Waypoint00' -- Possible downref: Non-RFC (?) normative reference: ref. 'XSong02' Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden 3 Expiration: May 2003 USC/ISI 4 File: draft-braden-2level-signal-arch-01.txt B. Lindell 5 USC/ISI 7 A Two-Level Architecture for Internet Signaling 9 November 3, 2002 11 Status of Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. This document is an Internet-Draft. 32 Abstract 34 This memo defines an architectural framework for a wide variety of 35 Internet signaling protocols. This framework has a two-level 36 organization: a common lower layer "transport" protocol together with 37 a suite of upper-level signaling protocols. The common lower level 38 protocol CSTP (Common Signaling Transport Protocol) provides a 39 transport-like service that may include reliable delivery and soft 40 state management. The upper layer protocols, which implement 41 algorithms and data structures specific to particular signaling 42 applications, are generically called ULSPs (Upper-layer Signaling 43 Protocols). This memo motivates the two-level design and describes 44 the service model, API, and operation of the lower level CSTP. 46 Table of Contents 48 0. Changes in This Version ....................................... 2 49 1. Introduction .................................................. 3 50 1.1 Background ................................................ 3 51 1.2 Terminology ............................................... 5 52 2. The CSTP Service Model ........................................ 7 53 2.1 CSTP Functions ............................................ 8 54 2.2 General Operation ......................................... 11 55 2.3 CSTP/ULSP API ............................................. 13 56 3. The CSTP Protocol ............................................. 16 57 3.1 Common Message Format ..................................... 16 58 3.2 CSTP/IP ................................................... 21 59 3.3 CSTP/TCP .................................................. 24 60 4. Open Issues ................................................... 24 61 5. Security Issues ............................................... 25 62 6. Acknowledgments ............................................... 25 63 Appendix A. RSVP Version 1 as a ULSP ............................. 26 64 References ....................................................... 28 66 0. Changes in This Version 68 o The text now foregrounds the support for two different 69 signaling models, with and without soft state. The previous 70 version had both models, but it was not somewhat buried. 72 o The term ALSP is replaced by ULSP. We considered adopting 73 one of the recently proposed sets of names for the CSTP and 74 ULSP layers, but after careful thought decided that for now 75 CSTP and ULSP are the best terms we can find. 77 o We included some NSIS working group issues, such as path- 78 coupled signaling. (With respect to "peer" vs. "neighbor", 79 see the first sentence of Section 2.) 81 o To make the job of the NSIS working group both harder (!), 82 this revision introduces the alternative to basing CSTP 83 either on TCP (section 3.3) or on the RSVP V1 mechanism 84 (section 3.2). This choice does not affect the API or the 85 ULSPs. 87 o We made several additions and corrections pointed out by 88 Xingguo Song (see Acknowledgments.) 90 o We interchanged the terms INFO and EVENT to provide more 91 intuitive terminology, and supplied some missing API calls. 93 1. Introduction 95 This memo presents the "Internet signaling protocol suite" (ISPS) 96 framework, a unified architectural framework for the specification 97 and implementation of a wide variety of Internet signaling 98 protocols. 100 The ISPS framework composes Internet signaling protocols using two 101 protocol levels: (1) a common lower level protocol and (2) a set 102 of upper-level signaling functions specific to particular 103 signaling applications. In particular, ISPS includes a common 104 lower-level protocol called CSTP ("Common Signaling Transport 105 Protocol") to implement transport and state-management functions, 106 plus a suite of higher-level "User-Layer Signaling Protocols" 107 (ULSPs). Each ULSP implements the algorithms and data structures 108 for a particular signaling task. 110 The remainder of this section presents background and motivation 111 and then introduces some terminology. Section 2 defines the 112 functions and API that CSTP provides to a ULSP. Section 3 113 describes two proposals for the CSTP protocol, CSTP/IP and 114 CSTP/TCP. 116 This memo makes several references to the RSVP Version 1 117 specifications [RFC2205, RFC2961]. Familiarity with these 118 specifications may be useful but is not required to read the 119 present memo. 121 1.1 Background 123 Under the basic Internet architecture, routers are unaware of 124 individual user flows or even flow aggregates; routers are 125 stateless except for routing tables that are used by all data 126 packets equally. While this basic model has proven extremely 127 powerful, it has become necessary to engineer into network nodes 128 some flow awareness for particular functions. These functions 129 include support for Quality-of-Service (QoS), control of 130 middleboxes, VPN control, and access-link management, for example. 131 Such flow-dependent functions generally require that some control 132 state be installed into network nodes, either statically by 133 configuration or dynamically using a "signaling" protocol. 135 The IETF defined RSVP Version 1 [RFC2205,Refresh00] specifically 136 for signaling to support the Integrated Services QoS model 137 [ISint93], but many RSVP extensions have been developed or 138 proposed to support a variety of other Internet signaling 139 applications. These applications include: QoS setup across 140 diff-serv clouds [intdiff00], setting up MPLS paths with QoS 142 [mpls00], provisioning VPNs [aggr01], QoS setup for access 143 networks [PCQoS99], NAT and firewall provisioning [TIST02], and 144 active interest filtering for distributed simulation [AIF01]. 145 With these extensions, RSVP Version 1 has in effect been expanded 146 to define a suite of Internet signaling protocols. 148 Basing all of these protocols on RSVP brings some unity that is 149 highly desirable. For example, the various signaling applications 150 benefit from RSVP's transport, routing, and soft-state mechanisms 151 as well as from its strongly-typed encoding. Using a common 152 protocol base also has benefits in design economy and 153 documentation. On the other hand, the complexity of the resulting 154 multi-featured RSVP implementations and the confusion of feature 155 interactions are the source of considerable complexity and some 156 confusion. 158 The unified ISPS framework described in this memo is designed to 159 organize and simplify the design and implementation of a wide 160 variety of signaling applications, while building on the most 161 successful aspects of RSVP V1. The two levels provide the 162 software engineering advantages of modularity, including 163 commonality, clarity, and reusability. For example, the framework 164 should allow the transport functions of CSTP to evolve 165 independently of the signaling application protocols. In 166 particular, this document proposes two quite different approaches 167 to CSTP in Section 3, a choice that should be transparent to every 168 ULSP. 170 The two-level decomposition of the ISPS framework could be the 171 first step towards a broader goal for unification: building the 172 various ULSPs using a common set software building blocks. For 173 example, it is possible that some sub-layering would be desirable 174 within the ULSP level. However, we don't yet undersand how to 175 take significant furthers step in this direction. 177 The Appendix A sketches how one would define a ULSP for QoS 178 signaling with all the functions and features of RSVP V1. 179 Although this member of the ISPS would not directly interoperate 180 with RSVP Version 1, a signaling gateway could be developed to 181 translate between RSVP Version 1 signaling messages and ISPS 182 messages. 184 1.2 Terminology 186 We first introduce some useful terminology. 188 o Network Nodes 190 We use the general term "network node", or simply "node", for 191 a router or middlebox. 193 o Flow 195 A flow is simply a distinguishable subset of the packet 196 stream. 198 o Signaling 200 The function of signaling is to set up state in one or more 201 network nodes, to provide some desired service for user data 202 flows. 204 This definition makes no assumption about the degree of 205 aggregation; a signaled flow may range from a micro-flow to 206 all the traffic in a tunnel or trunk. The definition also 207 does not assume that the endpoints of the signaling are end 208 systems, or that state must be installed in every node along 209 a path. 211 By this definition, signaling is concerned with state setup 212 along the path of some flow, rather than for example 213 configuring an entire region of the network. It may be that 214 some of the mechanisms for flow-related signaling would also 215 be useful for regional state setup (i.e., network 216 configuration), but regional state setup is outside the scope 217 of the present ISPS framework. 219 o Path-Coupled Signaling 221 Even for flow-related signaling, there is an engineering 222 choice about whether the signaling is primarily performed 223 in-line by the nodes through which the data flows, or whether 224 it is performed by a distinct set of signaling engines. The 225 first case is called "path-coupled signaling", while the 226 second is "path-uncoupled". 228 o Signaled path 230 Path-coupled signaling operates in the nodes along a 231 "signaled path" between two (or more, for multicast) 232 "signaling endpoints". A signaling endpoint at which user 233 data enters (or leaves) the signaled path is called " p-src" 234 (or "p-sink", respectively). The p-src and p-sink nodes for 235 a particular signaling instance might be end systems that are 236 the ultimate sources and destinations of the data packets 237 that establish the path, or they might be intermediate nodes 238 such as border routers or aggregation points or tunnel 239 endpoints. 241 Note that "src" (source) and "sink" terms are relative to the 242 data flow, not to the flow to signaling messages. Similarly, 243 in each node along the signaled path the directions 244 "upstream" and "downstream" are defined relative to the user 245 data flow that defines the path. 247 o ISPS Neighbors 249 We define two CSTP-capable nodes as (ISPS) "neighbors" if 250 they are connected by at least one path that includes no 251 other CSTP-capable nodes. Neighbors that are directly 252 connected, i.e., that have no nodes intervening, are "direct 253 neighbors". A CSTP-capable node may have at most one 254 neighbor through each point-to-point interface, but it may 255 have multiple neighbors through a broadcast or NBMA 256 interface. 258 Signaling messages are generally (but not necessarily) sent 259 hop-by-hop. Each hop is between neighbors, from an "h-src" 260 (hop source) node to a neighbor node called "h-sink" (hop 261 sink). 263 o SAPU 265 A "Signaling Application Protocol Unit" (SAPU) is the basic 266 transmission unit for signaling. A SAPU is derived from the 267 signaled state in the h-src node and it is used to set, 268 modify, or delete state in the h-sink node. 270 o Trigger, Refresh Messages 272 A "trigger message" installs, modifies, or deletes signaled 273 state, while a "refresh message" only refreshes existing 274 state, i.e., prevents it from timing out. 276 2. The CSTP Service Model 278 Under the two-level architecture, corresponding ULSP modules in 279 neighbor nodes are peers that communicate using the CSTP layer. 280 Roughly, ULSP and CSTP correspond respectively to application-layer 281 and transport layer protocols in the Internet stack. However, this 282 memo uses the term "level" rather than "layer" for the ULSP/CSTP 283 split, because they are more intertwined than strict protocol 284 layering allows. This is reflected in the API to be described in 285 Section 2.3. 287 Each ISPS message includes a ULSP identifier that selects a 288 particular ULSP. We assume that there will be a simple registration 289 space for ULSP identifiers. A major problem in developing particular 290 ULSPs will be to choose an appropriate functional modularity. There 291 might be a few very general and flexible ULSPs; at the other extreme, 292 there might be a great many ULSPs that differ only in particular 293 details. This choice is an engineering tradeoff whose criteria are 294 not yet clear. 296 The partition of functionality between CSTP and ULSP is a tradeoff 297 between generality and unity. A "thicker" CSTP level, i.e., one that 298 has more function, would provide greater unity among signaling tasks. 299 On the other hand, a "thicker" CSTP would also be less general and 300 more likely to constrain the range of signaling protocols that can be 301 achieved by any ULSP. This memo suggests a fairly "thin" CSTP, which 302 includes a set of functions that are closely interlinked and that are 303 generally useful for a broad range of signaling applications. For 304 example, this CSTP will support signaling tasks that require simplex 305 or full-duplex signaling, and it will support receiver- or sender- 306 initiated signaling. 308 DISCUSSION 310 Suppose that the the current Version 1 RSVP functionality were to 311 be mapped into a (CSTP, ULSP) pair (see Appendix A.) Neither 312 RSVP's receiver-oriented operation nor its reservation styles 313 [RFC2205] should appear in CSTP; these features would be 314 implemented only in the RSVP-specific ULSP module. 316 CSTP has only hop-by-hop semantics; it handles the (reliable and 317 secure) transmission of signaling state between neighbors and 318 (optionally) managing this as soft state. End-to-end signaling 319 semantics must be realized by the actions of the ULSP, which is 320 responsible for maintaining consistent signaled state along the path. 321 Upon receiving a new or modified SAPU, a ULSP module may send 322 appropriate SAPUs to other neighbors, to keep the state consistent 323 end-to-end (on the other hand, it may not, depending upon the 324 function to be performed.) 326 CSTP must not constrain the granularity of the data flow that defines 327 a signaling path (although an ULSP might.) The flow granularity 328 might range from micro-flows that are created by particular user 329 applications to highly-aggregated flows. On the other hand, each 330 ULSP is likely to be optimized for a particular flow granularity or 331 range of granularities. 333 It should be possible for signaling protocols supported by CSTP to 334 operate correctly through CSTP-incapable nodes. This requirement, 335 together with support for path-coupled signaling, can be met by 336 sending signaling messages downstream using the destination address 337 of the data. Such messages will automatically be forwarded correctly 338 through CSTP-incapable nodes. This mechanism in turn requires that 339 each CSTP hop intercept signaling messages from the data stream 340 [Waypoint00], process and perhaps modify them, and then forward them. 342 2.1 CSTP Functions 344 The CSTP level performs the following functions. These functions 345 are in general tightly coupled with each other, so they represent 346 a logical set for CSTP to implement. 348 o Reliable Delivery of Signaling Messages 350 Signaling operation must not be threatened by packet loss or 351 reordering. Therefore, CSTP provides reliable delivery of 352 trigger messages so that state can be reliably and promptly 353 added, changed, and explicitly removed. 355 DISCUSSION 357 The early design of RSVP Version 1 made the optimistic 358 assumption that signaling traffic could be protected by 359 QoS and that reordering would be rare. Experience later 360 showed that these assumptions could be violated 361 unacceptably often, so a reliable delivery mechanism 362 [Refresh00] was pasted onto RSVP Version 1. Reliable 363 delivery of trigger messages is a fundamental objective 364 for CSTP, although a particular ULSP may choose to not use 365 it. 367 o Ordered Delivery of SAPUs 369 The original RSVP v1 protocol spec [RFC2205] allowed network 370 reordering of signaling packets to create significant (e.g., 371 30 second) periods of erroneous reservation. The addition of 372 reliable delivery prevents this particular failure mode, but 373 it introduces the problem of delayed delivery of old 374 duplicate packets. Therefore, CSTP includes a mechanism to 375 ignore out-of-order trigger messages. 377 o Soft State Support 379 When signaling explicitly installs state in a node, there is 380 cause for concern about the robustness with which this state 381 will be removed. Besides system crashes, there is always the 382 possibility of programming errors that "leak" state. In the 383 somewhat chaotic multi-vendor environment of the Internet, it 384 is unwise to assume error-free interoperation of many 385 different implementations. CSTP therefore includes soft 386 state -- removing state that is not periodically refreshed or 387 explicitly torn down -- as a fundamental robustness 388 mechanism, although a particular ULSP may choose to not use 389 it. 391 o Fragmentation, Reassembly, and Bundling of SAPUs 393 CSTP must be able to fragment and reassemble SAPUs that 394 exceed one MTU. 396 DISCUSSION 398 We expect that elementary ISPS messages will be only a 399 little bit larger than the corresponding RSVP Version 1 400 messages; the majority of SAPUs should be under 200 bytes. 401 The addition of security credentials may lead to some 402 SAPUs O(1000) bytes, but SAPUs significantly larger than 403 this are expected to be rare. 405 Bundling -- carrying multiple small SAPUs in a single IP 406 datagram -- may be desirable for performance within CSTP. It 407 may be useful when cryptographic integrity checking is in 408 use, as it allows a single cryptographic checksum to be used 409 across all bundled messages. This is discussed further in 410 subsections 3.2 and 3.3. 412 o Congestion Control 414 It would seem that the signaling protocol and the network 415 configuration could ensure that signaling traffic will almost 416 always be small relative to the data flow. However, in 417 general all Internet traffic must be able to slow down in 418 response to congestion (in the absence of static or dynamic 419 partitioning of network bandwidth, e.g., by QoS.) 420 DISCUSSION 422 The flow of SAPUs normally has the general characteristics 423 of media streams: long-lived (in fact, never-ending), 424 somewhat bursty, streams of bytes. It should be possible 425 to throttle back signaling bandwidth between a pair of 426 nodes by slowing soft-state refreshes and by capping the 427 rate of change of existing state, for example. In this 428 regime, the techniques of TCP-friendly congestion control 429 may be applicable to CSTP. However, bursts of trigger 430 messages and retransmissions can also occur, so CSTP can 431 also have TCP-like characteristics. Thus, reliable 432 delivery introduces the need to dynamically compute the 433 appropriate value for retransmission timers, and this 434 computation must consider the round trip time (RTT) and 435 network congestion. 437 The two-level ISPS framework centralizes issues relating to 438 the volume and timing of network signaling traffic within the 439 common CSTP protocol. The CSTP module is in a position to 440 perform complex scheduling of signaling message 441 transmissions, taking into account the congestion at each 442 target node and the signaling load. For example, CSTP might 443 limit the rate of signaling traffic but still allow a burst 444 of signaling traffic when a route changes. 446 o Hop-by-Hop Security 448 Since the CSTP operates strictly hop/hop, CSTP is a natural 449 place to implement (optional) hop-by-hop integrity. We 450 suggest that the RSVP hop-by-hop integrity algorithms 451 [Integrity00] be used in CSTP. 453 o Neighbor List 455 A CSTP module maintains state that lists the node's 456 neighbors. This state may include the IP address of the 457 neighbor, the local interface used to reach it, and Boolean 458 flags giving important properties of the neighbor: ISPS- 459 capable and Direct-Neighbor. A node builds the neighbor list 460 as a result of receiving CSTP messages. The neighbor list 461 should be implemented as soft state that is deleted if it is 462 not refreshed. 464 An open issue is whether CSTP needs to provide an explicit 465 neighbor-discovery mechanism or even an up/down protocol 466 distinct from that provided by IP routing. 468 o Interface to Routing 470 In order to perform path-related signaling, it is necessary 471 that the signaling protocol be able to discover the route 472 taken by the corresponding data flow. This should be true 473 regardless of whether the signaling is path-coupled or path- 474 decoupled. It would clearly be an architectural mistake for 475 the signaling protocol to perform its own independent routing 476 calculation, so signaling must be able to query (and perhaps 477 influence, as in route pinning) IP routing. It makes sense 478 to centralize this interface to routing in the CSTP module, 479 to avoid replicating it in each ULSP. 481 Note that it would be useful to be able to hide the 482 complexities of multicast routing [Sections 3.3 and 3.9 of 483 RFC2205] within the CSTP level, to simplify ULSPs that need 484 to support multicast. However, the functionality does not 485 seem to divide cleanly across the CSTP/ULSP boundary, so that 486 a ULSP that supports multicast may have to cope with some of 487 the messy details of multicast routing. 489 2.2 General ISPS Operation 491 The ISPS framework operates in the following general manner. 493 o Suppose that an ULSP in the h-src node S needs to send an 494 SAPU containing signaled state to a peer ULSP on a neighbor 495 h-sink node T. The h-src ULSP issues a downcall to its local 496 CSTP module, passing the SAPU and a target IP address. 498 This target address may explicitly name node T, or T may be 499 determined implicitly because it intercepts the message that 500 was addressed to some downstream node, e.g., to p-dest or to 501 the ultimate destination address if different from p-dest. 503 o The CSTP level reliably delivers the SAPU to the 504 corresponding CSTP level in T, which then upcalls to the h- 505 dest ULSP to deliver the SAPU. 507 o At the request of the h-src ULSP, the SAPU contents can be 508 treated as soft state. In this case, the CSTP level in S 509 sends periodic refresh messages for the SAPU (unless the 510 message was deleting state). The CSTP level in T will 511 automatically time out the state and notify its local ULSP 512 via an upcall if the state is not refreshed in time. 514 o On the other hand, the SAPU contents may be "information" 515 that needs to be reliably communicated to a peer ULSP but not 516 retained as independent (soft) state in the h-sink CSTP. For 517 example, information state might be a QoS request that is 518 used for an admission control decision in a core node, which 519 does not retain the individual requests but only the 520 cumulative reservation (in the ULSP). 522 DISCUSSION 524 In this example of "stateless" admission control in the 525 core, the ULSP would need to keep track of the individual 526 requests somewhere at the edge of the network, in order to 527 reverse a reservation when a flow ceases. 529 Also note that a ULSP could use this information (non- 530 soft-state) option to transmit SAPUs to the peer ULSP and 531 then implement its own soft state mechanism at the ULSP 532 level. Bypassing the mechanism built into the CSTP in 533 this manner is generally undersirable, but it does provide 534 an escape for some unforeseen signaling requirement. 536 o The information included in an SAPU is logically a (, 537 ) pair. The part distinguishes the state 538 specified by the part from other state sent between 539 the same pair of neighbors. However, the distinction between 540 and within the SAPU is known only to the ULSP 541 module; CSTP treats the SAPU as opaque. 543 DISCUSSION: EXAMPLE FROM RSVP V1 545 For the equivalent of an RSVP Resv message, the part 546 of the SAPU would consist of the SESSION and NHOP objects 547 and perhaps (depending upon the STYLE) the FILTER_SPEC 548 objects. Other fields -- e.g., STYLE and FLOWSPEC -- 549 would be in the part. These complex rules on RSVP 550 V1 s would not be known by CSTP. 552 o The format of an SAPU is specific to the particular ULSP that 553 sends and receives it. However, many ULSPs will benefit 554 from using the typed "object" syntax and the object encoding 555 rules of RSVP Version 1, encoding an SAPU as a sequence of 556 elementary (type, length, value) triplets. 558 2.3 CSTP/ULSP API 560 This section defines a generic interface between CSTP and ULSP, 561 i.e., the generic ULSP API. 563 For simplicity we assume that the implementations of the two 564 levels are distinct, sharing no data structures. This means that 565 data structures must be passed across this interface by value and 566 that the CSTP must keep a shadow copy of the SAPU state to be 567 retransmitted. An actual implementation is likely to share data 568 structures between the two levels to avoid this inefficiency. (An 569 analogous relationship occurs between IP and TCP in most protocol 570 implementations). 572 Note that the CSTP level in designed to handle all of the event 573 timing, so the ULSP can be event-driven by upcalls from the CSTP. 575 2.3.1 Downcalls from the ULSP 577 An ULSP may issue the following downcalls to the CSTP. 579 o SendNewSAPU(SAPU, IP-target [, OIf], burst_flag) 580 -> SAPUid 582 This downcall causes the specified SAPU to be transmitted 583 reliably to the h-sink node specified or implied by 584 address IP-target; it also allocates and returns a unique 585 identifier SAPUid to the ULSP. If reliable delivery 586 fails, the CSTP level issues an asynchronous SendFailed() 587 upcall to the ULSP. If the SAPU is delivered and 588 acknowledged, the CSTP level sends periodic soft-state 589 refresh messages for it, until the ULSP makes a 590 SendModSAPU() or sendTearSAPU() downcall for the same 591 SAPUid. 593 In the downstream direction, IP-target may be the 594 signaling destination's IP address; the neighbor node on 595 the path to IP-target will intercept and process the 596 message. Otherwise, IP-target it must be the IP address 597 of a neighbor (h-sink). For a multicast IP-target 598 address, the caller may specify the outgoing interface OIf 599 to be used. 601 In order to retransmit for reliable delivery, the CSTP may 602 cache a copy of the SAPU. If an SAPU to be retransmitted 603 is not in the cache, the CSTP can issue a RegenSAPU() 604 upcall (see below) to ask the ULSP to regenerate the SAPU. 606 If a route change later causes loss of state in a 607 neighbor, CSTP will make a RegenSAPU() upcall to ask the 608 ULSP to reconstruct the original SAPU, and then send this 609 CSTP in a NEW trigger message containing a new SAPUid. 610 The upcall will also transmit a revised SAPUid to the 611 ULSP. 613 The burst_flag parameter is a boolean flag that can be 614 used by the CSTP level as a "hint" about when it can 615 efficiently bundle a set of successive calls (see Sections 616 3.2.3 and 3.3). When CSTP issues a burst of successive 617 calls to SendNewSAPU(), all except the last should have 618 this flag set to True. CSTP will make the decision about 619 when to bundle. This allows the CSTP to avoid the 620 introduction of substantial bundling delays. 622 o SendModSAPU(mod-SAPU, old-SAPUid, burst_flag ) 623 -> mod-SAPUid 625 Modify an existing SAPU that had identifier old-SAPUid to 626 be mod-SAPU with identifier mod-SAPUid. 628 Mod-SAPU will be reliably delivered and refreshed at the 629 neighbor specified or implied by IP-target, or else CSTP 630 will issue a SendFailed(mod-SAPUid, reason) upcall to the 631 ULSP. 633 o SendTearSAPU( SAPUid ) 635 Tear down (remove) the SAPU state that corresponds to 636 SAPUid. 638 o SendInfoSAPU(SAPU, IP-target [, OIf], burst_flag) 640 This call is used to send state to the specified target, 641 without treating it as soft state. This call is identical 642 to SendNewSAPU(), except the h-src CSTP does not retain 643 state after the transmission is acknowledged and does not 644 refresh the state, and the h-sink CSTP does not timeout 645 the state. 647 o SendEventSAPU(SAPU, IP-target [, OIf], burst_flag) 649 This call sends an SAPU with neither reliable delivery nor 650 refreshing, i.e., it is sent as a datagram. This is 651 called an "event" message. 653 2.3.2 Upcalls to the ULSP 655 The CSTP level may issue the following upcalls to the ULSP. 657 o SendFailed( SAPUid, reason ) 659 This upcall reports that the SendNewSAPU() or 660 SendModSAPU() operation failed for the specified SAPUid. 662 o RecvNewSAPU( SAPU, SAPUid, h-src ) 664 A new SAPU has been received from the node whose IP 665 address is h-src. SAPU is passed up for subsequent use in 666 a RecvTearSAPU upcall. 668 o RecvModSAPU( SAPU, SAPUid, h-src ) 670 An existing SAPU has been modified. 672 Note that the new/mod distinction here may not be needed; 673 the ULSP will discover the status when it looks up the 674 . However, the mod upcall is included in the 675 interface as a consistency check. 677 o RecvTearSAPU( SAPUid, h-src ) 679 This upcall may result from receiving a TEAR message for 680 the specified state or from a local soft-state timeout. 681 In either case, this call is a signal to the ULSP that the 682 specified SAPUid is henceforth invalidated. 684 o RecvInfo( SAPU, SAPUid, h-src) 686 This upcall delivers an SAPU that has been reliably 687 transmitted but is not retained in the CSTP level as soft 688 state. No refresh messages will be received for it, but a 689 subsequent TEAR message may result in a RecvTearSAPU 690 upcall for the same SAPUid. 692 o RecvEvent( SAPU, h-src) 694 This upcall delivers an Event SAPU, i.e., without reliable 695 delivery and without soft state refresh. 697 o RegenSAPU( SAPUid [, new-SAPUid] ) -> SAPU 699 This upcall requests that the ULSP regenerate and return 700 the SAPU corresponding to SAPUid. If present, the 701 optional new-SAPUid parameter is used to replace SAPUid as 702 the internal handle for this atom of signaled state. 704 Note: this list is incomplete. For example, API calls are 705 required for the routing interface (the RSRR interface of RSVP 706 V1 may be a useful guide here) and for the neighbor list. 708 3. The CSTP Protocol 710 There are two basic design choices for transporting ISPS messages: 711 use TCP connections, or explicitly program the required semantics 712 within CSTP. We refer to these alternatives as CSTP/TCP and CSTP/IP, 713 respectively; they are described in subsections 3.2 and 3.3. In 714 either case, a common message format, described in subsection 3.1, is 715 used. 717 3.1 Common Message Format 719 The basic CSTP message consists of a CSTP header, or "M-header", 720 and a payload that may include an SAPU. The M-header contains a 721 specification of the message type that determines the contents and 722 format of the payload. 724 CSTP transports SAPUs in DnSig (down-stream signaling) messages 725 and UpSig (upstream signaling) messages. We use the term "xSig" 726 to denote an elementary CSTP signaling message without specifying 727 the direction. 729 Each trigger message includes a unique identifier, the SAPUid. 730 The SAPUid is used as a handle on the SAPU that is known to the 731 CSTP (as opposed to the , buried within the SAPU, that the 732 CSTP cannot see). A SAPUid is used for for efficiently refreshing 733 the corresponding state and as a handle for state 735 The M-header includes: 737 o The length of the message, including the M-header and the 738 payload. 740 o A ULSP identifier 742 o The CSTP message type for this message (see below). 744 o The IP address h-src of the node that sent this message. 746 o A list of zero or more SAPUids 747 The first two bytes of the SAPU must be its length in bytes; 748 otherwise, the SAPU format is entirely opaque to CSTP. 750 The nine currently-defined CSTP message types are as follows. 751 They are shown schematically in functional notation with the type 752 as the first parameter. In practice most the parameters listed 753 here are carried explicitly in the M-header. 755 xSig(NEW, h-src, SAPUid, SAPU, R) 757 xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R) 759 xSig(TEAR, h-src, SAPUid) 761 xSig(REFRESH, h-src, SAPUid, R) 763 xSig(ACK, h-dest, SAPUid-list) 765 xSig(NACK, h-src, SAPUid) 767 xSig(INFO, h-src, SAPUid, SAPU) 769 xSig(EVENT, h-src, SAPUid, SAPU) 771 xSig(CHALLENGE, h-src, challenge-object) 773 xSig(RESPONSE, h-src, challenge-object) 775 xSig(ERROR, h-dest, SAPUid) 777 Here: 779 o Every message contains the IP address of its originator, h- 780 src. In most but not all cases this address is the same as 781 the source IP address of the ISPS packet. For simplicity we 782 specify that h-src will always appear explicitly in a CSTP 783 header. It is used to build neighbor state. 785 o R specifies the refresh time for the SAPU (see [RFC2205]). 787 o For the MOD message, the sending ULSP must ensure that the 788 new SAPU with identifier SAPUid and the old SAPU with 789 identifier old-SAPUid share the same parts. 791 o The NEW and MOD messages send soft state, and REFRESH 792 messages refresh that state. The INFO message sends an SAPU 793 reliably but does not retain or it as soft state. The EVENT 794 message sends an SAPU on-time and unreliably. 796 o The CHALLENGE and RESPONSE messages are used to initialize 797 the keyed hash integrity check [Integrity00]. The 798 is carried as a CSTP-level SAPU, which is 799 a special case; all other SAPUs are opaque to CSTP and 800 carried on behalf of an ULSP. is defined 801 in [Integrity00]. 803 Figures 1a and 1b show a state diagram for operation of CSTP 804 at an h-src node, and Figure 2 summarizes the corresponding 805 states at the receiver node h-sink. Here SendNewSAPU(), 806 SendModSAPU(), and SendTearSAPU() represent down calls from 807 the ULSP to the CSTP to install a new SAPU, modify an 808 existing SAPU, or delete an SAPU, respectively. xSig(type) 809 represents a CSTP message of a specific type. TO-R and TO-T 810 refer to refresh and state timeouts, respectively. 812 +--------+ 813 | (none) | 814 +--------+ +-------+ 815 | SendNewSAPU() SendModSAPU() | | 816 | ------------- -------------- | | 817 V send xSig(new) Send xSig(MOD) V | 818 +-----------+ +----------+ | 819 | | SendModSAPU() | | | 820 | NEW |------------------------->| MOD |---+ 821 | | send xSig(MOD) +---->| | 822 +-----------+ / +--| | 823 | ^ | / / +----------+ 824 | | | SendTearSAPU() / / | 825 | | +-----------------/---/-----------+ | 826 recv xSig(ACK) | | send xSig(TEAR) / / | | 827 --------------- | | / / | | 828 X | recv xSig(NACK) / / | | 829 | --------------- / recv xSig(ACK) | | 830 | send xSig(NEW) / / ---------- | | 831 | | / / X | | 832 | | SendMod() / / | | 833 TO-R | | -------- / / | | 834 -------- | | send xSig(MOD)/ | | 835 send xSig(REFR) | | / / | | 836 +-----+ | | / / | | 837 | V V | / / V V 838 | +-----------+ / / +----------+ 839 +----| |--+ / | | 840 | INSTALLED |<----+ SendTearSAPU() | TORN | 841 | |-------------------------->| | 842 +-----------+ send xSig(TEAR) +----------+ 843 | 844 Recv xSig(ACK)|TO-T | 845 ------------------- V 846 X +--------+ 847 | (none) | 848 +--------+ 849 Figure 1a: H-Src CSTP State Diagram (Soft State) 850 +--------+ 851 | (none) |------------------+ 852 +--------+ | 853 | SendInfoSAPU() | 854 | --------------- | 855 | send xSig(INFO ) | 856 V | 857 +-----------+ | SendEventSAPU() 858 | | | --------------- 859 | INFO | | send xSig(EVENT) 860 | | | 861 +-----------+ | 862 | | 863 Recv xSig(ACK)|TO-T | | 864 ------------------- | | 865 X V | 866 +--------+ | 867 | (none) |<------------------+ 868 +--------+ 869 Figure 1b: H-Src CSTP State Diagram (Hard State and Datagrams) 871 +--------+ 872 +-----------------| (none) |------------------+ 873 | +--------+ | 874 | | | 875 | | | 876 resv xSig(NEW) | recv xSig(TEAR) | recv xSig(INFO) | 877 ---------------- | -------------- | --------------- | 878 send xSig(ACK) & | reset timer | send xSig(ACK) & | 879 upcall RecvNewSAPU() | +-----+ | upcall RecvInfo() | 880 V V | | | 881 +-----------+ | | | 882 | STATE |---+ | recv xSig(EVENT)| 883 | TIMING | | ----------------- | 884 +-----------+ | upcall RecvEvent()| 885 | | | 886 Recv xSig(TEAR)|TO-T | | | 887 ------------------- | | | 888 X | V | 889 | +--------+ | 890 +---------------->| (none) |<-----------------+ 891 +--------+ 893 Figure 2: H-Sink CSTP State Diagram) 895 3.2 CSTP/IP 897 CSTP/IP uses the RSVP V1 signaling message paradigm. It includes 898 a version of the RSVP "refresh reduction" extensions [Refresh00] 899 to provide reliable delivery of trigger messages, rejection of old 900 duplicates, and refreshing of state. 902 These mechanisms use the SAPUid as handle on the state. Note that 903 we are overloading this unique identifier by using it both for (1) 904 transmitting and refreshing SAPUs and for (2) local handles in the 905 API interfaces of h-src and h-sink nodes. In an actual 906 implementation distinct SAPUids could be used in the API, if that 907 were more efficient. 909 3.2.1 Example: Sending New State 911 Sending new signaled state involves the following sequence of 912 steps. Some secondary parameters are omitted here for 913 simplicity. 915 1. The local ULSP issues the following downcall to its CSTP, 916 passing the new SAPU: 918 SendNewSAPU( SAPU, IP-target, [OIf]) -> SAPUid 920 For downstream transmission, the target IP address P- 921 target will be either the target signaling destination 922 address p-dest or the address h-sink of a neighbor. For 923 upstream transmission, it must be a neighbor address h- 924 sink. The optional Outgoing InterFace (OIf) parameter is 925 needed when IP-target is a multicast address. 927 The CSTP: 929 o generates an SAPUid, 931 o creates a local send state block, 933 o builds and sends the trigger message: 935 xSig(NEW, h-src, SAPUid, SAPU) 937 to the IP-target address, 939 o sets a retransmit timer, 941 o and returns the SAPUid to the ULSP, which records 942 this handle. 944 2. If the retransmit timer goes off before the NEW message is 945 acknowledged, the local CSTP retransmits the trigger 946 message. This is repeated until either an ACK is received 947 or a limit is reached. In the latter case, the CSTP 948 issues the upcall: 950 SendFailed(SAPUid, SAPU) 952 and deletes the send state block. 954 3. Otherwise, when the CSTP receives a xSig(ACK, SAPUid) 955 message, it stops retransmitting and starts sending 956 periodic refresh messages to IP-target: 958 xSig(REFRESH, h-src, SAPUid) 960 4. If the CSTP receives a xSig(NACK, SAPUid) message, it 961 returns to step 2 to (re-)transmit the trigger message. 963 5. When the NEW message is received at the h-sink node that 964 was implied or specified by IP-target, the remote CSTP: 966 o Creates a local receive state block, 968 o passes the SAPU to the remote ULSP via an upcall: 970 RecvNewSAPU(SAPU, h-src) 972 o and returns an ACK message. 974 3.2.2 Ordered Delivery in CSTP/IP 976 Under soft-state signaling, old trigger messages should always 977 be ignored. This can be accomplished by introducing a 978 monotone-increasing sequence number in trigger messages. 979 Following the example of the Refresh Reduction extensions to 980 RSVP V1 [Refresh00], we can overload the SAPUid to serve as a 981 sequence number as well as a handle on reservation state. An 982 h-src node generates monotone increasing values for new SAPUids 983 to be sent to a given h-sink. The h-sink node then: 985 (1) remembers the largest SAPUid seen so far from h-src; 987 (2) processes as a trigger message a SAPU received with a 988 larger SAPUid; 990 (3) treats the message as a refresh if the received SAPUid 991 matches that of existing state from h-src; and otherwise, 993 (4) ignores the message and sends a NACK. 995 When a node crashes and restarts, losing its state, some 996 mechanism is required to reliably instruct its neighbors to 997 reset their latest sequence numbers. When a route changes and 998 a REFRESH message is answered with a NACK, h-src must send the 999 new trigger message with a new SAPUid; h-src must also upcall 1000 to inform its ULSP that the SAPUid has changed for the existing 1001 state. 1003 An alternative approach to ordered delivery would be to use the 1004 sequence number that is already present in the hop-by-hop 1005 cryptographic integrity check mechanism [Integrity00]. The 1006 integrity mechanism also includes a Challenge/Response 1007 mechanism to robustly (and securely) reset the sequence number 1008 in neighbors at startup. 1010 If a route change later causes loss of state in a neighbor, 1011 CSTP will make a RegenSAPU() upcall to ask the ULSP to 1012 reconstruct the original SAPU, and then send this CSTP in a NEW 1013 trigger message containing a new SAPUid. The upcall will also 1014 transmit the revised SAPUid to the ULSP. 1016 3.2.3 Fragmentation and Bundling 1018 In order to handle both fragmentation and bundling, an 1019 additional CSTP/IP header is prepended to each bundled message 1020 or fragment of a large message. This outer header is called 1021 the FB-header (fragment/bundle). Then a bundle of small 1022 messages has the form: 1024 * 1026 (where star denotes none or more), and a fragment of a large 1027 message has the form: 1029 1031 The BF-header contains: 1033 o The total length of the datagram in bytes 1035 o A fragment offset and MF ("More Fragments") bit 1037 o A checksum or keyed hash integrity object 1039 3.3 CSTP/TCP 1041 An alternative to building a reliable, ordered delivery mechanism 1042 into CSTP, as in RSVP v1, would be to use TCP for delivery of CSTP 1043 messages. Using this CSTP/TCP, each CSTP module would open a TCP 1044 connection to each of its neighbors and use it for all signaling 1045 traffic. This traffic would be a series of CSTP messages as , pairs, defined in subsection 3.1. 1048 TCP would provide reliable and ordered delivery, fragmentation and 1049 reassembly, and congestion control. This should considerably 1050 simplify the CSTP level of the ISPS framework compared to CSTP/IP. 1051 On the other hand, using TCP may give the CSTP less control over 1052 exactly how it reacts to congestion or to a burst of traffic. 1054 We believe that the API described in subsection 3.1 can be made to 1055 work equally well for CSTP/TCP and CSTP/IP, allowing the same ULSP 1056 to operate over either lower-level protocol. It is unclear 1057 whether only one or both of these CSTP protocols should be 1058 standardized. It may be that different situations will favor one 1059 or the other approach. If both are defined, then there must be 1060 some interoperability mechanism to allow a particular neighbor 1061 pair to agree on which is to be used. 1063 It might seem that bundling would add no functionality to 1064 CSTP/TCP. However, performance may be significantly improved by 1065 including in each TCP segment all the small CSTP messages that 1066 will fit. If cryptographic integrity is in use, it will be 1067 important to compute a single cryptographic hash across each 1068 segment, and a new per-segment header must be introduced to carry 1069 this hash. This is analogous to the FB header introduced in 1070 Section 3.2.3, except that under CSTP/TCP it will not have a 1071 fragmentation function, only a bundling function. 1073 4. Open Issues 1075 A number of issues are left unresolved in this memo. In the 1076 following list of these issues, the first three are fundamental 1077 issues of the NSIS working group agenda. The rest are more specific 1078 technical issues. 1080 1. A broad design question is how to partition the space of 1081 signaling applications into ULSPs (Section 2.) 1083 2. This memo describes two alternative approaches to CSTP, CSTP/IP 1084 and CSTP/TCP (Section 3). Should one, or both, be standardized? 1086 3. Section 3.1 describes a generic API, which would be mapped into 1087 various implementation-specific interfaces. However, if it is 1088 desirable to create a market in third-party ULSP software, it 1089 will be necessary to standardize on a real API. Should we 1090 define a real API now? 1092 4. The ULSP API defined in Section 3.1 is incomplete. It omits a 1093 way to communicate neighbor information to a ULSP, and it also 1094 omits the common interface to routing. 1096 o Is an explicit neighbor discovery mechanism necessary or 1097 desirable (Section 2.1), or can CSTP simply learn of neighbors 1098 from signaling traffic and verify their status from routing? 1100 5. Should CSTP support another delivery mode for NEW and MOD: 1101 unreliable delivery but with refresh? (Note that this would 1102 correspond to the service provided by the version of RSVP 1103 defined in [RFC2205], before the Refresh Reduction Extensions 1104 were defined.) Similarly, should CSTP support the option of 1105 unreliable delivery for TEAR? 1107 6. Is MOD logically necessary, and is it useful? 1109 7. The spec is currently missing a preemption mechanism, which can 1110 do a reverse teardown. That is, it should be possible to 1111 initiate a teardown in the direction counter to the setup 1112 direction. 1114 8. Possible support for bidirectional reservations needs further 1115 thought. 1117 5. Security Considerations 1119 The CSTP protocol may support hop-by-hop integrity using the 1120 algorithms of RSVP version 1 [Integrity00]. Policy issues -- e.g., 1121 user authentication and access control as well as accounting -- are 1122 the province of each ULSP. Some ULSPs will wish to incorporate the 1123 COPS mechanisms for secure end-to-end authentication and access 1124 control [COPS00]. 1126 6. Acknowledgments 1128 The conception behind this memo is not original. One of the 1129 advances in STream protocol II (ST-II) [RFC1191] over its predecessor 1130 ST was the explicit definition of a reliable hop-by-hop control sub- 1131 protocol called ST Control Message Protocol (SCMP). We believe that 1132 CSTP reflects some important advances over SCMP, for example soft 1133 state management. 1135 We are grateful for several Xingguo Song of Concordia University for 1136 pointing out several errors and omissions in the previous version of 1137 this memo. He discovered these problems in the course of validating 1138 CSTP using the formal specification language SDL. 1140 APPENDIX A. RSVP Version 1 as an ULSP 1142 To write an ULSP specification for the base Version 1 RSVP protocol 1143 of RFC 2205, we can adopt nearly all of RFC2205. This is largely 1144 because many of the issues handled by CSTP are dealt with in the 1145 Refresh Reduction extension document [Refresh00], not in RFC 2205. 1146 The Refresh Reduction document [Refresh00] would be entirely 1147 obsoleted by our ISPS proposal, although we have suggested adopting 1148 its basic concepts. 1150 Looking at RFC 2205 in detail, we find the following. 1152 o Section 1 of RFC 2205 would be little changed. This section 1153 discusses the objectives of RSVP and defines a session, a 1154 flowspec, a filterspec, receiver-initiated reservations, scope, 1155 reservation merging, and styles. 1157 o Section 2 of RFC 2205 which describe the RSVP protocol 1158 mechanisms in general terms, would be changed only where it 1159 describes soft state and specific RSVP Version 1 message types. 1160 RSVP Version 1 message types would become a combination of SAPU 1161 type and CSTP message types, as shown in the table below. Note 1162 that a few of the RSVP Version 1 message types, e.g., Bundle, 1163 simply disappear into mechanisms included in CSTP. 1165 o Section 3 of RFC 2205 contains the functional specification of 1166 RSVP Version 1, and section 3.1 defines RSVP Version 1 message 1167 syntax and semantics. Each definition that maps 1168 into ISPS becomes a definition. The Common Header is 1169 replaced by an SAPU header that contains only a length and an 1170 SAPU type. The INTEGRITY object is omitted since it will now 1171 appear in the CSTP header. Otherwise, Section 3.1 would be 1172 unchanged. 1174 o Some discussion would be required of exactly how the RSVP ULSP 1175 should invoke the downcalls to CSTP and the upcalls from CSTP. 1177 The message types of RSVP Version 1 will be mapped as follows, using 1178 the ISPS design of this memo. 1180 RSVP Version 1 Message Type SAPU Type CSTP Message Type 1181 __________________________ _____________ _________________ 1183 Path Path NEW or MOD 1184 Resv Resv NEW or MOD 1185 Srefresh Path or Resv REFRESH 1186 ACK Path or Resv ACK or NACK 1187 PathTear Path TEAR 1188 ResvTear Resv TEAR 1189 PathErr PathErr EVENT 1190 ResvErr, ResvConf ResvErr EVENT 1191 DREQ DiagReq EVENT 1192 DREP DiagRep EVENT 1193 Integrity Challenge (none) CHALLENGE 1194 Integrity Response (none) RESPONSE 1195 Bundle (none) (CSTP header) 1196 ResvTearConf ?? 1198 References 1200 [aggr01] Baker, F. et. al., "Aggregation of RSVP for IPv4 and IPv6 1201 Reservations", RFC 3175, September 2001. 1203 [AIF01] Keaton, M., Lindell, R., Braden, R., and S. Zabele, "Active 1204 Multicast Information Dissemination", submitted to conference, 1205 April 2001. 1207 [CM01] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 1208 3124, June 2001. 1210 [COPS00] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, 1211 R., and A. Sastry, "The COPS (Common Open Policy Service) 1212 Protocol", RFC 2748, January 2000. 1214 [intdiff00] Bernet, Y. et al, "A Framework for Integrated Services 1215 Operation over Diffserv Networks", RFC 2998, November 2000. 1217 [Integrity00] Baker, F., Lindell, R., and M. Talwar, "RSVP 1218 Cryptographic Authentication", RSVP 2747, January 2000. 1996. 1220 [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated 1221 Services in the Internet Architecture: an Overview", RFC 1633, 1222 June 1994. 1224 [ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated 1225 Services", RFC 2210, September 1997. 1227 [mpls00] Swallow, G., et al, "RSVP-TE: Extensions to RSVP for LSP 1228 Tunnels", , IETF, Sept 1229 2001. 1231 [optical00] Rajagopalan, B., "LMP, LDP and RSVP Extensions for 1232 Optical UNI Signaling", , IETF, October 2001. 1235 [PCQoS99] "PacketCable(tm) Dynamic Quality-of-Service 1236 Specification", PKT-SP-DQOS-I01-991201, Cable Television 1237 Laboratories, Inc., 1999. 1239 [Refresh00] Berger, L., et. al., "RSVP Refresh Overhead Reduction 1240 Extensions", , IETF, June 1241 2000. 1243 [RFC2205] Braden., R. Ed., et. al., "Resource ReSerVation Protocol 1244 (RSVP) -- Version 1 Functional Specification", RFC 2205, 1245 September 1997. 1247 [TIST02] Shore, M., "The TIST (Topology-Insensitive Service 1248 Traversal) Protocol", , IETF, May 1249 2002. 1251 [Waypoint00] The path-oriented concept was explored in an expired 1252 Internet Draft: Lindell, B., "Waypoint -- A Path Oriented 1253 Delivery Mechanism for IP based Control, Measurement, and 1254 Signaling Protocols"", , IETF, 1255 November 2000. 1257 [XSong02] Xingguo Song, "Specification and Validation of the Common 1258 Signaling Transport Protocol in SDL", Thesis, Concordia 1259 University, Montreal, Canada, September 2002. 1261 Authors' Addresses 1263 Bob Braden 1264 USC Information Sciences Institute 1265 4676 Admiralty Way 1266 Marina del Rey, CA 90292 1268 Phone: (310) 448-9173 1269 EMail: Braden@ISI.EDU 1271 Bob Lindell 1272 USC Information Sciences Institute 1273 4676 Admiralty Way 1274 Marina del Rey, CA 90292 1276 Phone: (310) 448 8727 1277 EMail: Lindell@ISI.EDU