idnits 2.17.00 (12 Aug 2021) /tmp/idnits19600/draft-braden-2level-signal-arch-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 12, 2001) is 7494 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: 'RFC1191' is mentioned on line 104, but not defined == Missing Reference: 'RFC2961' is mentioned on line 121, but not defined == Missing Reference: 'OIf' is mentioned on line 499, but not defined == Missing Reference: 'SAPU' is mentioned on line 686, but not defined == Unused Reference: 'ISrsvp96' is defined on line 995, 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. 'Waypoint00' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden 3 Expiration: May 2002 USC/ISI 4 File: draft-braden-2level-signal-arch-00.txt B. Lindell 5 USC/ISI 7 A Two-Level Architecture for Internet Signaling 9 November 12, 2001 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 suggests a two-level organization for Internet signaling 35 protocols: a common lower layer called the Common Signaling Transport 36 Protocol (CSTP), and an upper-level signaling protocol to implement 37 the algorithms and data structures specific to a particular signaling 38 application. CSTP features would include reliable delivery and soft 39 state management. 41 1. Introduction 43 1.1 A Signaling Protocol Suite 45 Version 1 of RSVP was designed specifically to perform QoS 46 signaling for Integrated Services [ISInt93]. However, many RSVP 47 extensions have been developed or proposed to support a variety of 48 other Internet signaling applications. These applications 49 include: 51 o QoS setup across diff-serv clouds [intdiff00] 53 o Setting up MPLS paths with QoS [mpls00] 55 o Provisioning VPNs [aggr01] 57 o Configuring optical networks [optical00] 59 o QoS setup for PacketCable [PCQoS99] 61 o Active interest filtering for distributed simulation [AIF01]. 63 With these extensions, RSVP Version 1 has in effect been expanded 64 to define a suite of Internet signaling protocols. Basing all of 65 these protocols on RSVP brings some unity that is highly 66 desirable. For example, the signaling applications listed above 67 benefit from RSVP's transport, routing, and soft-state mechanisms 68 as well as from its strongly-typed encoding. Using a common 69 protocol base also has benefits in design economy and 70 documentation. On the other hand, the complexity of the resulting 71 multi-featured RSVP implementations and the confusion of feature 72 interactions are the source of considerable complexity and some 73 confusion. 75 This memo proposes an approach to building an "Internet signaling 76 protocol suite" (ISPS) with improved modularity. It falls short 77 of a a more ambitious long-range goal, building the ISPS in a 78 modular fashion out of common software building blocks. We don't 79 yet know how to perform a modular decomposition for Internet 80 signaling. This memo proposes a simpler step: the composition of 81 Internet signaling protocols from two protocol levels: (1) a 82 common lower level that performs transport-layer functions and (2) 83 a set of upper-level signaling functions that are specific to 84 particular signaling applications. 86 In particular, we suggest a common lower-level protocol called 87 CSTP ("Common Signaling Transport Protocol") to implement 88 transport and soft-state functions. CSTP will support a suite of 89 higher-level "Application-Layer Signaling Protocols" (ALSPs). 90 Each ALSP will implement the algorithms and data structures for a 91 particular signaling task. CSTP together with the set of ALSPs 92 will implement the Internet signaling protocol suite (ISPS). This 93 modularity will allow the transport functions of CSTP to evolve 94 more-or-less independently of the signaling applications. 96 We use the term "level" rather than "layer" for the ALSP/CSTP 97 split, because traditional protocol layering implies an 98 independence that will not exist in this case. It is true that 99 ALSP and CSTP correspond roughly to application-layer and 100 transport layer protocols, respectively; however, they are inter- 101 dependent in ways that will be described below. 103 The conception behind this memo is not original. One of the 104 advances in STream protocol II (ST-II) [RFC1191] over its 105 predecessor ST was the explicit definition of a reliable hop-by- 106 hop control sub-protocol called ST Control Message Protocol 107 (SCMP). We believe that CSTP reflects some important advances 108 over SCMP, for example soft state management. 110 This memo is an initial sketch of our two-level architecture for 111 Internet signaling. This specification is incomplete in many 112 respects, and since the ideas in this memo have not yet been 113 subjected to either simulation or prototyping, it may very well 114 include errors. However, we are offering a possible starting 115 point for further protocol engineering. 117 The remainder of this section introduces some terminology and then 118 summarizes the requirements on CSTP. Section 2 presents a general 119 overview of CSTP, and Section 3 contains the beginning of a 120 protocol specification. This memo makes many references to the 121 RSVP Version 1 specifications [RFC2205, RFC2961]; the reader is 122 assumed to be generally familiar with these RFCs. Of course, an 123 ultimate specification for CSTP would have to be self-sufficient. 125 1.2 Terminology 127 We first introduce some useful terminology. 129 o Path-Directed Signaling 131 Any protoocol that is used to set up state in network 132 entities -- e.g., DHCP or IGMP -- might be called a 133 "signaling protocol". However, our two-level ISPS 134 architecture is intended to support RSVP-like signaling 135 applications that install, modify, and remove state in 136 routers and other entities along the path of some particular 137 data flow. We call this paradigm "path-directed" signaling 138 [Waypoint00] 140 Path-directed signaling operates in the nodes along a data 141 path between two (or more, for multicast) "signaling 142 endpoints". This data path is the "signaled path", which has 143 an initial node " p-src" and one or more terminal nodes "p- 144 sink". 146 For each signaling activity in a node along the signaled 147 path, the directions "upstream" and "downstream" are defined 148 relative to the data flow that defines the path. Thus, data 149 flows downstream from p-src to p-sink, while signaling may 150 occur in one or both directions. The P-src and p-sink nodes 151 might be end systems that are the ultimate sources and 152 destinations of the data packets that establish the path, or 153 they might be intermediate nodes such as border routers or 154 aggregation points or tunnel endpoints. 156 o CSTP Neighbors 158 We define two CSTP-capable nodes as "neighbors" if they are 159 connected by at least one path that includes no other CSTP- 160 capable nodes. Neighbors that are directly connected, i.e., 161 with no nodes intervening, are "direct neighbors". A CSTP- 162 capable node may have at most one neighbor through each 163 point-to-point interface, but it may have multiple neighbors 164 through a broadcast or NBMA interface. 166 Signaling messages are generally sent hop-by-hop. Each hop 167 is between neighbors, from an "h-src" (hop source) node to a 168 neighbor node called "h-sink" (hop sink). 170 o SAPU 172 A Signaling Application Protocol Unit (SAPU) is the basic 173 transmission unit for signaling. A SAPU is derived from the 174 signaled state in the h-src node and it is used to set, 175 modify, or delete state in the h-sink node. 177 o Trigger, Refresh Messages 179 A "trigger message" installs, modifies, or deletes signaled 180 state, while a "refresh message" only refreshes existing 181 state, i.e., prevents it from timing out. 183 1.3 CSTP Requirements 185 The partition of functionality between CSTP and ALSP is a tradeoff 186 between generality and unity. A "thicker" CSTP level, i.e., one 187 that has more function, would provide greater unity among 188 signaling tasks. On the other hand, a "thicker" CSTP would also 189 be less general and more likely to constrain the range of 190 signaling protocols that can be achieved by any ALSP. This memo 191 suggests a fairly "thin" CSTP, which includes a set of functions 192 that are closely interlinked and that are generally useful for a 193 broad range of signaling applications. For example, this CSTP 194 will support signaling tasks that require simplex or full-duplex 195 signaling, and it will support receiver- or sender-initiated 196 signaling. 198 DISCUSSION 200 Suppose that the the current Version 1 RSVP functionality were 201 to be mapped into a (CSTP, ALSP) pair (see Appendix A.) 202 Neither RSVP's receiver-oriented operation nor its reservation 203 styles [RFC2205] should appear in CSTP; these features would be 204 implemented only in the RSVP-specific ALSP module. 206 The Common Signaling Transport Protocol (CSTP) should meet the 207 following general objectives. 209 o Support for Path-Directed Signaling 211 CSTP must support path-directed signaling, although some 212 ALSPs may not make use of this capability. All end-to-end 213 signaling semantics would be realized by the actions of an 214 ALSP; CSTP itself does not have end-to-end semantics. CSTP 215 handles only the dynamics of reliably transmitting signaling 216 state between neighbors, h-src to h-sink, and of refreshing 217 this as soft state. 219 CSTP should not constrain the granularity of the data flow 220 that defines a signaling path (although an ALSP might.) The 221 flow granularity might range from micro-flows that are 222 created by particular user applications to highly-aggregated 223 flows. 225 o RSVP Version 1 Support 227 It must be possible to support the functionality of any 228 flavor of RSVP Version 1 using the combination of CSTP with 229 an appropriate ALSP. We could therefore consider the (CSTP, 230 ALSP) design as RSVP Version 2, although CSTP is deliberately 231 designed to be more general than a strictly RSVP-like 232 protocol. 234 The CSTP design that is presented here would not directly 235 interoperate with RSVP Version 1, due to differing packet 236 formats. However, a signaling gateway could be developed to 237 translate RSVP Version 1 signaling messages to and from 238 (CSTP, ALSP) messages. 240 o Reliable Delivery of Signaling Messages 242 Signaling operation must not be threatened by packet loss or 243 reordering. Thus, CSTP must provide reliable delivery of 244 trigger messages so that state can be reliably and promptly 245 added, changed, and explicitly removed. 247 The division of function between CSTP and the ALSP will ease 248 future modifications in the service model. For example, 249 should it be decided that reliable delivery of refresh 250 messages was desirable, this service could be added to CSTP 251 with no changes to the ALSPs. 253 The reliable delivery algorithm must consider fragmentation. 254 CSTP should be able to retransmit individual fragments of 255 large SAPUs, to avoid bad error statistics when fragments are 256 dropped. On the other hand, SAPUs larger than a very small 257 number of MTUs are expected to be rare, so selective 258 acknowledgments may not be very useful; a simple cumulative 259 ACK should be sufficient. 261 DISCUSSION 263 The early design of RSVP Version 1 made the optimistic 264 assumption that signaling traffic could be protected by 265 QoS and that reordering would be rare. Experience later 266 showed that these assumptions could be violated 267 unacceptably often, so a reliable delivery mechanism 268 [Refresh00] was pasted onto RSVP Version 1. Reliable 269 delivery of trigger messages is a fundamental objective 270 for CSTP, although a particular ALSP may choose to not use 271 it. 273 o Ordered Delivery of SAPUs 275 The original RSVP v1 protocol spec [RFC2205] allowed network 276 reordering of signaling packets to create significant (e.g., 277 30 second) periods of erroneous reservation. The addition of 278 reliable delivery prevents this particular failure mode, but 279 it introduces the problem of delayed delivery of old 280 duplicate packets. Therefore, the CSTP outlined in this memo 281 includes a mechanism to ignore out-of-order trigger messages. 283 o Soft State Support 285 Even with reliable message delivery, there is cause for 286 concern about the robustness with which unused state is 287 removed. In the somewhat chaotic multi-vendor environment of 288 the Internet, it is unwise to assume error-free 289 interoperation of many different implementations. Bugs that 290 leave behind orphan state are particularly serious. We 291 therefore include soft state -- removing state that is not 292 periodically refreshed or explicitly torn down -- as a 293 fundamental robustness mechanism of CSTP, although again a 294 particular ALSP may choose to not use it. 296 o Fragmentation, Reassembly, and Bundling of SAPUs 298 CSTP must be able to fragment and reassemble SAPUs that 299 exceed one MTU. 301 We expect that elementary ISPS messages will be only a 302 little bit larger than the corresponding RSVP Version 1 303 messages; the majority of SAPUs should be under 200 bytes. 304 The addition of security credentials may lead to some 305 SAPUs O(1000) bytes, but SAPUs signficantly larger than 306 this are expected to be rare. 308 Bundling -- carrying multiple small SAPUs in a single IP 309 datagram -- may be desirable for performance, especially when 310 there is a burst of signaling requests. Such a burst might 311 be caused by a route change or by some external event. On 312 the other hand, bundling can reduce the number of packets by 313 only roughly a factor of 10. While this factor may be 314 useful, it is not generally scalable. The bundling 315 requirement may need further consideration. 317 o Full Internet-Layer Support 319 CSTP should support the full range of Internet-layer 320 protocols, including IPv4 and IPv6, unicast and multicast 321 delivery, and IPSEC for data security. 323 o Partial Deployment 325 It must be possible for signaling protocols supported by CSTP 326 to operate correctly through CSTP-incapable nodes. This 327 requirement, together with support for path-directed 328 signaling, can be met by sending signaling messages 329 downstream using the destination address of the data. Such 330 messages will automatically be forwarded correctly through 331 CSTP-incapable nodes. This mechanism in turn requires that 332 each CSTP hop intercept signaling messages from the data 333 stream [Waypoint00], process and perhaps modify them, and 334 then forward them. 336 o Congestion Control 338 It would seem that the signaling protocol and the network 339 configuration could ensure that signaling traffic will almost 340 always be small relative to the data flow. However, all 341 Internet traffic should be responsive to congestion. 343 Signaling data normally has the characteristics of packet 344 video data: a long-lived (in fact, never-ending), somewhat 345 bursty, stream of data. It should be possible to throttle 346 back signaling bandwidth between a pair of nodes by slowing 347 soft-state refreshes and by capping the rate of change of 348 existing state, for example. In this regime, the techniques 349 of TCP-friendly congestion control may be applicable to CSTP. 350 However, bursts of trigger messages and retransmissions can 351 also occur, so CSTP can also have TCP-like characteristics. 352 Thus, reliable delivery introduces the need to dynamically 353 compute the appropriate value for retransmission timers, and 354 this computation must consider the round trip time (RTT) and 355 network congestion. 357 The two-level signaling design centralizes all issues 358 relating to the volume and timing of network signaling 359 traffic within the common CSTP protocol. The CSTP module is 360 in a position to perform complex scheduling of signaling 361 message transmissions, taking into account the congestion at 362 each target node and the signaling load. For example, CSTP 363 might limit the rate of signaling traffic but still allow a 364 burst of signaling traffic when a route changes. CSTP might 365 be a good candidate for the "Congestion Manager" [CM01]. 367 o Hop-by-hop integrity 369 Since the CSTP operates strictly hop/hop, it seems a natural 370 place to implement (optional) hop-by-hop integrity, using the 371 RSVP algorithms [Integrity00] for example. 373 All of these functions except the last are tightly coupled with 374 each other, so they represent a logical set for CSTP to implement. 376 Integrity is included in the CSTP simply to provide common support 377 for an important signaling component. 379 There are some common functions that do not seem to belong in 380 CSTP. For example, it could be tempting to try to limit knowledge 381 of unicast and multicast routing and addressing to the CSTP. 382 Thus, the CSTP might provide Logical Interface Handles (LIHs) to 383 support asymmetric paths [Section 3.3, RFC2205] as well as the 384 Iapp logic that is required because of complexities of multicast 385 routing [Section 3.9, RFC2205]. However, at present it appears 386 that the ALSP must know about unicast or multicast routing and 387 LIHs. 389 At this stage, the reader is likely to be wondering whether it 390 would not be better to base CSTP on TCP, rather than building new 391 TCP-like mechanisms for fragmentation/reassembly, reliable 392 delivery, and congestion control. A virtue of the two-level 393 architecture suggested in this memo is that a switch to CSTP over 394 TCP would not change the ALSPs or the ALSP/CSTP interface. 396 2. Overview of CSTP 398 2.1 General 400 The two-level architecture will operate in the following general 401 manner. 403 o To send a SAPU containing signaled state to a target neighbor 404 node, the ALSP will issue a downcall to its local CSTP 405 module. The local CSTP will encapsulate the SAPU in a 406 signaling message and send it to the CSTP module in the 407 target node. The destination address for this message may be 408 p-dest (or the ultimate destination address if different from 409 p-dest) for a downstream message, or it may be the IP address 410 of the specific neighbor h-sink. 412 o The local CSTP will retransmit this message as necessary 413 until an acknowledgment is received from the target CSTP. 415 o Once the transfer is acknowledged, the local CSTP will begin 416 sending refresh messages for it (unless the message was 417 deleting state). Note that the ALSP will not be involved in 418 reliable delivery or refresh of this SAPU after the initial 419 downcall. 421 The source node's ALSP module derives a SAPU from its stored state 422 and its CSTP carries the SAPU to the h-sink node, whose ALSP 423 updates its stored state to reflect the SAPU. The ALSP is 424 responsible for maintaining consistent signaled state along the 425 path. Thus, upon receiving a new or modified SAPU from a node h- 426 src, an ALSP module may invoke its CSTP to forward appropriate 427 SAPUs to other neighbors. 429 The information included in an SAPU is logically a (, 430 ) pair. The part distinguishes the state specified 431 by the part from other state sent between the same pair of 432 neighbors. However, the distinction between and 433 within the SAPU is known only to the ALSP module; CSTP treats the 434 SAPU as opaque. 436 CSTP messages may be sent as IP or UDP datagrams. 438 We believe that it is useful to retain the typed "object" syntax 439 and the object encoding rules of RSVP Version 1, so that an SAPU 440 will typically be a encoded as a sequence of elementary (type, 441 length, value) triplets. 443 2.2 Reliable Delivery 445 The CSTP suggested here incorporates a version of the RSVP 446 "refresh reduction" extensions [Refresh00] to provide reliable 447 delivery of trigger messages and rejection of old duplicates. 448 Note that the CSTP handles most or all of the event timing, so the 449 ALSP can be event-driven by upcalls from the CSTP. 451 For reliable delivery, each trigger message includes a unique 452 identifier, the SAPUid. The SAPUid is used as a handle on the 453 SAPU that is known to the CSTP (as opposed to the , buried 454 within the SAPU, that the CSTP cannot see). A SAPUid is used for 455 acknowledging receipt of a trigger-message SAPU and for 456 efficiently refreshing the corresponding state. 458 EXAMPLE FROM RSVP V1 460 For the equivalent of an RSVP Resv message, the part of 461 the SAPU would consist of the SESSION and NHOP objects and 462 perhaps (depending upon the STYLE) the FILTER_SPEC objects. 463 Other fields -- e.g., STYLE and FLOWSPEC -- wouild be in the 464 part. These complex rules on RSVP V1 s would not 465 be known by CSTP. 467 Note that some RSVP Version 1 objects may be mapped into the 468 CSTP message header rather than included in a SAPU. For 469 example, in RSVP the next/previous hop IP address is coupled 470 with the Logical Interface Handle (LIH) in a single data object 471 (NHOP/PHOP). Section 3 shows that the CSTP header includes the 472 next/previous hop IP address, but an ALSP would include the LIH 473 in its SAPU only when it was needed by the particular signaling 474 application. 476 CSTP transports SAPUs in DnSig (down-stream signaling) messages 477 and UpSig (upstream signaling) messages. We use the term "xSig" 478 to denote an elementary CSTP signaling message without specifying 479 the direction. 481 A CSTP module must maintain state that lists the node's neighbors. 482 This state includes the IP address of the neighbor and the local 483 interface used to reach it. This per-neighbor state also includes 484 two Boolean flags giving important properties of the neighbor, 485 e.g., ISPS-capable and Direct-Neighbor. A node builds the 486 neighbor list as a result of receiving CSTP messages. The 487 neighbor list should be implemented as soft state that is deleted 488 if it is not refreshed. 490 2.3 Example: Sending New State 492 Sending new signaled state involves the following sequence of 493 steps. Some secondary parameters are omitted here for simplicity, 494 but they appear in the more detailed spec in Section 3. 496 1. The local ALSP issues the following downcall to its CSTP, 497 passing the new SAPU and a target IP address IP-target. 499 SendNewSAPU( SAPU, IP-target, [OIf]) -> SAPUid 501 For downstream transmission, IP-target will be either the 502 target signaling destination address p-dest or the address 503 h-sink of a neighbor. For upstream transmission, it must be 504 a neighbor address h-sink. The optional Outgoing InterFace 505 (OIf) parameter is needed when IP-target is a multicast 506 address. 508 The CSTP: 510 o generates an SAPUid, 512 o creates a local send state block, 514 o builds and sends the trigger message: 516 xSig(NEW, h-src, SAPUid, SAPU) 518 to the IP-target address, 520 o sets a retransmit timer, 522 o and returns the SAPUid to the ALSP, which records this 523 handle. 525 2. If the retransmit timer goes off before the NEW message is 526 acknowledged, the local CSTP retransmits the trigger message. 527 This is repeated until either an ACK is received or a limit 528 is reached. In the latter case, the CSTP issues the upcall: 530 SendFail(SAPUid, SAPU) 532 and deletes the send state block. 534 3. Otherwise, when the CSTP receives a xSig(ACK, SAPUid) 535 message, it stops retransmitting and starts sending periodic 536 refresh messages to IP-target: 538 xSig(REFRESH, h-src, SAPUid) 540 4. If the CSTP receives a xSig(NACK, SAPUid) message, it returns 541 to step 2 to (re-)transmit the trigger message. 543 5. When the NEW message is received at the h-sink node that was 544 implied or specified by IP-target, the remote CSTP: 546 o Creates a local receive state block, 548 o passes the SAPU to the remote ALSP via an upcall: 550 RecvNewSAPU(SAPU, h-src) 552 o and returns an ACK message. 554 2.4 Ordered Delivery 556 Under soft-state signaling, old trigger messages should always be 557 ignored. This can be accomplished by introducing a monotone- 558 increasing sequence number in trigger messages. 560 Following the example of the Refresh Reduction extensions to RSVP 561 v1 [Refresh00], we can overload the SAPUid to serve as a sequence 562 number as well as a handle on reservation state. An h-src node 563 would generate monotone increasing values for new SAPUids to be 564 sent to a given h-sink. The h-sink node would then: (1) remember 565 the largest SAPUid seen so far from h-src; (2) if a received 566 SAPUid is larger, process that SAPU as a trigger message; (3) if 567 the received SAPUid matches that of existing state from h-src, 568 treat the message as a refresh; (4) otherwise ignore the message 569 and send a NACK. 571 It of course necessary to get the details of this mechanism right. 572 When a node crashes and restarts, losing its state, some mechanism 573 is required to reliably instruct its neighbors to reset their 574 latest sequence numbers. When a route changes and a REFRESH 575 message is answered with a NACK, h-src must send the new trigger 576 message with a new SAPUid; h-src must also upcall to inform its 577 ALSP that the SAPUid has changed for the existing state. 579 An alternative approach to ordered delivery would be to use the 580 sequence number that is already present in the hop-by-hop 581 cryptographic integrity check mechanism [Integrity00]. The 582 integrity mechanism also includes a Challenge/Response mechanism 583 to robustly (and securely) reset the sequence number in neighbors 584 at startup. 586 3. CSTP Specification 588 3.1 Signaling Messages 590 The nine currently-defined CSTP message types are as follows. 591 They are shown schematically in functional notation with the type 592 as the first parameter. 594 xSig(NEW, h-src, SAPUid, SAPU, R) 596 xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R) 598 xSig(TEAR, h-src, SAPUid) 600 xSig(REFRESH, h-src, SAPUid, R) 602 xSig(ACK, h-dest, SAPUid-list) 604 xSig(NACK, h-src, SAPUid) 606 xSig(EVENT, h-src, SAPUid, SAPU) 608 xSig(CHALLENGE, h-src, challenge-object) 610 xSig(RESPONSE, h-src, challenge-object) 612 Here: 614 o Every message contains the IP address of its originator, h- 615 src. In most but not all cases this address is the same as 616 the source IP address of the ISPS packet. For simplicity we 617 specify that h-src will always appear explicitly in a CSTP 618 header. It is used to build neighbor state. 620 o R specifies the refresh time for the SAPU (see [RFC2205]). 622 o For the MOD message, the sending ALSP must ensure that the 623 new SAPU with identifier SAPUid and the old SAPU with 624 identifier old-SAPUid share the same parts. 626 The EVENT message sends an SAPU reliably but does not continue to 627 refresh it. Thus, it represents a one-time signal or "event". 629 The CHALLENGE and RESPONSE messages are used to initialize the 630 keyed hash integrity check [Integrity00]. The 631 is carried as a CSTP-level SAPU, which is a special case; all 632 other SAPUs are opaque to CSTP and carried on behalf of an ALSP. 633 is defined in [Integrity00]. 635 3.2 Header Format 637 In order to handle both fragmentation and bundling, the CSTP 638 header could be divided into two parts: an outer header called the 639 "B-header" ("B" for "bundle") and an inner header called the "M- 640 header" ("M" for "message"). The basic CSTP packet format would 641 be the sequence: 643 [SAPU] 645 The optional SAPU is included if the CSTP header type in calls for it. The other parameters shown in the previous 647 section would be in or . 649 Multiple (, [SAPU]) pairs, prefixed by a single , can be sent in a single MTU-sized datagram; this is 651 bundling. On the other hand, if the basic packet format is too 652 large to fit into a single datagram, the (, SAPU) pair 653 can be fragmented into datagrams that are each prefixed with a 654 . 656 This header syntax can be summarized by the following BNF for a 657 message: 659 { }* [ ] 661 The detailed engineering of the headers is being deferred for the 662 present. However, in general the headers will contain the 663 following information fields. 665 The B-header contains: 667 o The total length of the datagram in bytes 669 o A fragment offset and MF ("More Fragments") bit 671 o A checksum or keyed hash integrity object 673 o An ALSP identifier 675 o The R value for all messages bundled into this datagram. 677 The ALSP identifier is used to select the ALSP, and hence the 678 signaling task, that is in use. We assume that there will be a 679 simple registration space for ALSP identifiers. We believe this 680 will work in practice, although the number of different ALSPs 681 could be at worst 2**n, where n is the number of RSVP extensions. 682 In practice, we expect only a few distinct combinations to exist. 684 The M-header contains: 686 o The length of the (, [SAPU]) pair; this is the byte 687 offset of the next M-header in the case of bundled messages. 689 o The CSTP message type for this message 691 o A list of zero or more SAPUids 693 If the CSTP message type calls for an SAPU, it follows immediately 694 after the M-header. The first two bytes of the SAPU must be its 695 length in bytes; otherwise, the SAPU format is entirely opaque to 696 CSTP. 698 This account omits details like version numbers, IP address format 699 specification, and flags. 701 3.3 State Diagram for CSTP 703 The stages in handling a particular SAPU can be summarized by the 704 state diagram for the sending CSTP in h-src; it is shown in Figure 705 1. Here SendNewSAPU(), SendModSAPU(), and SendTearSAPU() 706 represent down calls from the ALSP to the CSTP to install a new 707 SAPU, modify an existing SAPU, or delete an SAPU, respectively. 708 xSig() represents a CSTP message encapsulating an ALSP payload. 709 TO-X refers to a retransmission timer firing, while TO-R and TO-T 710 refer to refresh and state timeouts, respectively. 712 +--------+ 713 TO-X | (none) | TO-X 714 ------------ +--------+ ------------- 715 send xSig(NEW) | SendNew () send xSig(MOD) 716 +-----+ | ------------- +-----+ 717 | V V send xSig(new) | V 718 | +-----------+ | +----------+ 719 +---| | SendMod() +---| | 720 | NEW |------------------------->| MOD | 721 | | send xSig(MOD) +---->| | 722 +-----------+ / +--| | 723 | ^ | / / +----------+ 724 | | | SendTear() / / | 725 | | +-----------------/---/-----------+ | 726 recv xSig(ACK) | | send xSig(TEAR) / / | | 727 --------------- | | / / | | 728 X | recv xSig(NACK) / / | | 729 | --------------- / recv xSig(ACK) | | 730 | send xSig(NEW) / / ---------- | | 731 | | / / X | | 732 | | SendMod() / / | | 733 TO-R | | -------- / / TO-X | | 734 -------- | | send xSig(MOD)/ ------------- | | 735 send xSig(REFR) | | / / send xSig(TEAR)| | 736 +-----+ | | / / +-----+ | | 737 | V V | / / | V V V 738 | +-----------+ / / | +----------+ 739 +----| |--+ / +---| | 740 |ESTABLISHED|<----+ SendTear() | TEAR | 741 | |-------------------------->| | 742 +-----------+ send xSig(TEAR) +----------+ 743 | 744 Recv xSig(ACK)|TO-T | 745 ------------------- V 746 X +--------+ 747 | (none) | 748 +--------+ 749 Figure 1: H-Src CSTP State Diagram 751 3.4 CSTP/ALSP Interface 753 This section defines a generic interface between CSTP and ALSP. 754 For simplicity we assume that the two levels are distinct, sharing 755 no data structures. This means that data structures must be 756 passed across this interface by value and that the CSTP must keep 757 a shadow copy of the SAPU state to be retransmitted. An actual 758 implementation is likely to share data structures between the two 759 levels to avoid this inefficiency. (An analogous relationship 760 occurs between IP and TCP in most protocol implementations). 762 3.4.1 Down Calls 764 An ALSP issues the following downcalls to the CSTP. 766 o Send New SAPU 768 SendNewSAPU(SAPU, IP-target [, OIf], burst_flag) 770 -> SAPUid 772 This call sends the specified SAPU reliably to the 773 neighbor specified or implied by address IP-target, and 774 then allocates and returns a unique identifier SAPUid. If 775 reliable delivery fails, CSTP issues an asynchronous 776 SendFail() upcall to the ALSP. If the SAPU is delivered 777 and acknowledged, CSTP then sends periodic soft-state 778 refresh messages for it. CSTP continues the refresh 779 autonomously until the ALSP makes a SendModSAPU() or 780 sendTearSAPU() downcall for the same SAPUid. 782 If a route change later causes loss of state in a 783 neighbor, CSTP will make a RegenSAPU() upcall to ask the 784 ALSP to reconstruct the original SAPU, and then send this 785 CSTP in a NEW trigger message containing a new SAPUid. 786 The upcall will also transmit the revised SAPUid to the 787 ALSP. 789 In the downstream direction, IP-target may be the 790 signaling destination's IP address; the neighbor h-sink on 791 the path to IP-target will intercept and process the 792 message. Otherwise, IP-target it must be the IP address 793 of a neighbor (h-sink). For a multicast IP-target 794 address, the caller may specify the outgoing interface OIf 795 to be used. 797 In order to retransmit for reliable delivery, the CSTP may 798 cache a copy of the SAPU. If an SAPU to be retransmitted 799 is not in the cache, the CSTP can issue a RegenSAPU() 800 upcall to ask the ALSP to reconstruct the SAPU. 802 The burst_flag parameter is a boolean flag that can be 803 used by the CSTP as a "hint" about when it can efficiently 804 bundle a set of successive calls. When CSTP issues a 805 burst of successive calls to SendNewSAPU(), all except the 806 last should have this flag set to True. CSTP will make 807 the decision about when to bundle. This allows the CSTP 808 to avoid the introduction of substantial bundling delays. 810 o Send Modified SAPU 812 SendModSAPU(mod-SAPUid, mod-SAPU, old-SAPUid, burst_flag ) 814 Modify an existing SAPU that had identifer old-SAPUid to 815 be mod-SAPU with identifier mod-SAPU. 817 Mod-SAPU will be reliably delivered and refreshed at the 818 neighbor specified or implied by IP-target, or else CSTP 819 will issue a SendFail(mod-SAPUid, reason) upcall to the 820 ALSP. 822 o Remove Existing SAPU 824 SendTearSAPU( SAPUid ) 826 Tear down the SAPU that corresponds to SAPUid. 828 o Send "Event" 830 It is possible to send an SAPU reliably but not refresh it 831 as soft state. Such a transmission is called an "event". 833 SendEventSAPU(SAPU, IP-target [, OIf], burst_flag) 835 This call is identical to SendNewSAPU(), except CSTP does 836 not retain state after the transmission is acknowledged or 837 times out. 839 o Send "Info" Message 841 An SAPU can be sent with neither reliable delivery nor 842 refreshing, i.e., sent as a datagram. This is called an 843 "Information" or "Info" message. 845 SendInfoSAPU(SAPU, IP-target [, OIf], burst_flag) 847 3.4.2 UPcalls to ALSP 849 The CSTP has the following upcalls to the ALSP. 851 o Notify of Send Failure 853 SendFail( SAPUid, reason ) 855 Reports to ALSP that the SendNewSAPU() or SendModSAPU() 856 operation failed for specified SAPUid. 858 o ALSP Receive New SAPU 860 RecvNewSAPU( SAPU, h-src ) 862 A new SAPU has been received from the node whose IP 863 address is h-src. 865 o ALSP Receive Modified SAPU 867 RecvModSAPU( SAPU, h-src ) 869 An existing SAPU has been modified. Note that the ALSP 870 can parse the SAPU and find the in order to identify 871 the older SAPU state to be replaced, so the SAPUid is not 872 passed up. 874 Note also that the new/mod distinction here is not really 875 needed; the ALSP will discover the status when it looks up 876 the . It is included in the interface only as a 877 consistency check. 879 o ALSP Notified of Teardown Received 881 RecvTearSAPU( SAPUid, h-src ) 883 o Request ALSP to Regenerate SAPU 885 RegenSAPU( SAPUid [, new-SAPUid] ) -> SAPU 887 Requests that the ALSP regenerate and return the SAPU 888 corresponding to SAPUid. If the optional new-SAPUid 889 parameter is present, the ALSP also uses it to replace 890 SAPUid as its internal handle for this atom of signaled 891 state. 893 APPENDIX A. RSVP Version 1 as an ALSP 895 To write an ALSP specification for the base Version 1 RSVP protocol of 896 RFC 2205, we can adopt nearly all of RFC2205. This is largely because 897 many of the issues handled by CSTP are dealt with in the Refresh 898 Reduction extension document [Refresh00], not in RFC 2205. The Refresh 899 Reduction document [Refresh00] would be entirely obsoleted by our ISPS 900 proposal, although we have suggested adopting its basic concepts. 902 Looking at RFC 2205 in detail, we find the following. 904 o Section 1 of RFC 2205 would be little changed. This section 905 discusses the objectives of RSVP and defines a session, a flowspec, 906 a filterspec, receiver-initiated reservations, scope, reservation 907 merging, and styles. 909 o Section 2 of RFC 2205 which describe the RSVP protocol mechanisms 910 in general terms, would be changed only where it describes soft 911 state and specific RSVP Version 1 message types. RSVP Version 1 912 message types would become a combination of SAPU type and CSTP 913 message types, as shown in the table below. Note that a few of the 914 RSVP Version 1 message types, e.g., Bundle, simply disappear into 915 mechanisms included in CSTP. 917 o Section 3 of RFC 2205 contains the functional specification of RSVP 918 Version 1, and section 3.1 defines RSVP Version 1 message syntax 919 and semantics. Each definition that maps into ISPS 920 becomes a definition. The Common Header is replaced by 921 an SAPU header that contains only a length and an SAPU type. The 922 INTEGRITY object is omitted since it will now appear in the CSTP 923 header. Otherwise, Section 3.1 would be unchanged. 925 o Some discussion would be required of exactly how the RSVP ALSP 926 should invoke the downcalls to CSTP and the upcalls from CSTP. 928 The message types of RSVP Version 1 will be mapped as follows, using the 929 ISPS design of this memo. 931 RSVP Version 1 Message Type SAPU Type CSTP Message Type 932 __________________________ _____________ _________________ 934 Path Path NEW or MOD 935 Resv Resv NEW or MOD 936 Srefresh Path or Resv REFRESH 937 ACK Path or Resv ACK or NACK 938 PathTear Path TEAR 939 ResvTear Resv TEAR 940 PathErr PathErr EVENT 941 ResvErr, ResvConf ResvErr EVENT 942 DREQ DiagReq EVENT 943 DREP DiagRep EVENT 944 Integrity Challenge (none) CHALLENGE 945 Integrity Response (none) RESPONSE 946 Bundle (none) (CSTP header) 947 ResvTearConf ?? 949 APPENDIX B. OPEN ISSUES 951 The following issues were left unresolved in the CSTP specification in 952 this document. 954 o Should the spec support optional modes of unreliable delivery but 955 with refresh for NEW or MOD, or optional unreliable delivery for 956 TEAR? 958 o Should there be an explicit upstream/downstream indicator in the 959 CSTP header? 961 o Is MOD logically necessary, and is it useful? 963 o Are there important efficiency issues in not piggy-backing ACKs, 964 NACKs upon existing messages? 966 Security Considerations 968 The CSTP protocol introduced in this document may support hop-by-hop 969 integrity using the algorithms of RSVP version 1 [Integrity00]. 970 Incorporation of the COPS mechanisms for secure end-to-end 971 authentication and access control of signaling is a matter for 972 further study. 974 References 976 [aggr01] Baker, F. et. al., "Aggregation of RSVP for IPv4 and IPv6 977 Reservations", RFC 3175, September 2001. 979 [AIF01] Keaton, M., Lindell, R., Braden, R., and S. Zabele, "Active 980 Multicast Information Dissemination", submitted to conference, April 981 2001. 983 [CM01] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 984 3124, June 2001. 986 [intdiff00] Bernet, Y. et al, "A Framework for Integrated Services 987 Operation over Diffserv Networks", RFC 2998, November 2000. 989 [Integrity00] Baker, F., Lindell, R., and M. Talwar, "RSVP 990 Cryptographic Authentication", RSVP 2747, January 2000. 1996. 992 [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services 993 in the Internet Architecture: an Overview", RFC 1633, June 1994. 995 [ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated Services", 996 RFC 2210, September 1997. 998 [mpls00] Swallow, G., et al, "RSVP-TE: Extensions to RSVP for LSP 999 Tunnels", , IETF, Sept 2001. 1001 [optical00] Rajagopalan, B., "LMP, LDP and RSVP Extensions for Optical 1002 UNI Signaling", , IETF, 1003 October 2001. 1005 [PCQoS99] "PacketCable(tm) Dynamic Quality-of-Service Specification", 1006 PKT-SP-DQOS-I01-991201, Cable Television Laboratories, Inc., 1999. 1008 [Refresh00] Berger, L., et. al., "RSVP Refresh Overhead Reduction 1009 Extensions", , IETF, June 1010 2000. 1012 [RFC2205] Braden., R. Ed., et. al., "Resource ReSerVation Protocol 1013 (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1014 1997. 1016 [Waypoint00] The path-oriented concept was explored in an expired 1017 Internet Draft: Lindell, B., "Waypoint -- A Path Oriented Delivery 1018 Mechanism for IP based Control, Measurement, and Signaling 1019 Protocols"", , IETF, November 2000. 1021 Authors' Addresses 1023 Bob Braden 1024 USC Information Sciences Institute 1025 4676 Admiralty Way 1026 Marina del Rey, CA 90292 1028 Phone: (310) 448-9173 1029 EMail: Braden@ISI.EDU 1031 Bob Lindell 1032 USC Information Sciences Institute 1033 4676 Admiralty Way 1034 Marina del Rey, CA 90292 1036 Phone: (310) 448 8727 1037 EMail: Lindell@ISI.EDU