idnits 2.17.00 (12 Aug 2021) /tmp/idnits19276/draft-fu-rsvp-multicast-analysis-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: ---------------------------------------------------------------------------- == 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 a Security Considerations section. ** 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 24, 2002) is 7270 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) == Unused Reference: '5' is defined on line 461, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-req has been published as RFC 3726 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '1') -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-demeer-nsis-analysis-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-01) exists of draft-braden-2level-signal-arch-00 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2362 (ref. '9') (Obsoleted by RFC 4601, RFC 5059) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group X. Fu 3 Internet-Draft Technical University Berlin 4 Expires: December 23, 2002 C. Kappler 5 H. Tschofenig 6 Siemens AG 7 June 24, 2002 9 Analysis on RSVP Regarding Multicast 10 draft-fu-rsvp-multicast-analysis-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 23, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 RSVP version 1 has been designed for optimally support multicast. 42 However, in reality multicast is being used much less frequently than 43 anticipated. Still, even for unicast (one sender, one receiver) 44 communication, full-fledged multicast-enabled RSVP signaling must be 45 used. As pointed out in the NSIS requirement draft, multicast would 46 not be necessarily required for an NSIS signaling protocol. This 47 draft analyses ingredients of RSVP Version 1 which are affected by 48 multicast, and derives how these ingredients may look like if 49 multicast is not supported. We find removing multicast capability 50 from RSVP will make it and its extensions considerably more light- 51 weight. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Multicast-Influenced Ingredients in RSVP . . . . . . . . . . . 4 57 2.1 Reservation Styles . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Receiver-Initiated Reservation . . . . . . . . . . . . . . . . 4 59 2.3 Path/Resv Two-Pass Signaling Message Exchange . . . . . . . . 4 60 2.4 State Management in Routers . . . . . . . . . . . . . . . . . 5 61 2.5 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6 Non-RSVP Region Handling . . . . . . . . . . . . . . . . . . . 5 63 3. Removing Multicast in RSVP . . . . . . . . . . . . . . . . . . 6 64 3.1 No Reservation Styles . . . . . . . . . . . . . . . . . . . . 6 65 3.2 Sender-Initiated Reservation . . . . . . . . . . . . . . . . . 6 66 3.3 Path One-Way Signaling Message for Reservation . . . . . . . . 6 67 3.4 Simpler State Management in Routers . . . . . . . . . . . . . 7 68 3.5 Simplified Error Handling . . . . . . . . . . . . . . . . . . 7 69 3.6 Impact on Non-RSVP Region Problem . . . . . . . . . . . . . . 8 70 4. Removing Multicast in Some RSVP Extensions . . . . . . . . . . 9 71 4.1 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Benefits of Removing Multicast in RSVP . . . . . . . . . . . . 11 74 6. Security Aspect . . . . . . . . . . . . . . . . . . . . . . . 12 75 7. Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 77 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 As a signaling protocol designed specifically for the Internet, RSVP 84 Version 1 (RSVPv1) [8] distinguishes itself by a number of 85 fundamental ways, particularly, soft state management, two-pass 86 signaling message exchanges, receiver-based resource reservation and 87 separation of QoS signaling from routing (in the sense that RSVP 88 messages follow normal IP routing). However, RSVP end-to-end 89 signaled QoS for the Internet has not become a reality. One reason 90 for this is regarded the complexity brought by multicast [2][3]. In 91 fact, vast majority of applications do not use multicast in reality. 92 Some multicast protocols (e.g., PIM-SM [9]) even consider multicast 93 as a function built on top of unicast routing rather than as an 94 integral part of it. We notice that multicast is not listed as a 95 (mandatory) requirement in the NSIS requirements draft [1]. 97 This draft analyses ingredients of RSVP Version 1 which are needed to 98 support multicast. Compared with standard RSVP, the following 99 ingredients could be simplified or would even not be needed if 100 multicast is removed from RSVP: 102 o Reservation styles are not needed; 104 o Sender-initiated rather than receiver-initiated; 106 o Path one-way signaling instead of Path/Resv two-pass signaling 107 message exchange (although ACK/NACK is still needed); 109 o Only Path state is needed in routers, and NHOP/PHOP/LIH are not 110 necessary in a Path state; 112 o Error handling is simpler; 114 o Non-RSVP region problems become easier. 116 This list might not be comprehensive, but we believe it covers main 117 features. We find that removing multicast capability from RSVP will 118 make it and its extensions on aggregation and proxy support 119 considerably more light-weight. 121 2. Multicast-Influenced Ingredients in RSVP 123 This section analysis the ingredients in RSVPv1 [7][8] influenced by 124 multicast, they are: (1) reservation styles, (2) receiver-initiated 125 reservation, (3) Path/Resv two-pass signaling message exchanges, (4) 126 state management in routers, (5) error handling, and (6) non-RSVP 127 region techniques. In this document terms "reservation" and "(QoS) 128 signaling" are used interchangeably. 130 2.1 Reservation Styles 132 To accommodate the multipoint-to-multipoint multicast applications, 133 RSVP was designed to support a vector of reservation attributes 134 called the "style". There are two attributes in RSVPv1: 136 Sharing attribute, with value "Shared" (all senders share a single 137 reservation) or "Distinct" (every sender has a seperate 138 reservation); 140 Sender Selection attribute, with value "Explicit" (select 141 explicitly a specific sender), "Wildcard" (applies to all 142 senders). 144 2.2 Receiver-Initiated Reservation 146 Receiver-initiated is critical for RSVP to setup multicast sessions 147 with a large number of receivers. RSVP is optimized for a large 148 number of receivers with heterogeneous request, and therefore deploys 149 the receiver-initiated approach: a receiver initiates a reservation 150 request at a leaf of the multicast distribution tree, travelling 151 towards the sender. Whenever a reservation is found to already exist 152 in a node in the distribution tree, the new request will be merged 153 with the existing reservation. This could result in fewer signalling 154 operations for the RSVP nodes close to the sender, and new receivers 155 are handled completely by the receivers and the network without 156 bothering the sender. In comparison, for sender-initiated 157 reservation, when the reservation request travels up the multicast 158 tree towards the intended heterogeneous receivers, it is necessary to 159 distribute its reservation request information to all hops on the 160 multicast tree between source and receivers. This implies gathering 161 receivers' QoS information from receivers beforehand and results in 162 more signaling overhead. 164 2.3 Path/Resv Two-Pass Signaling Message Exchange 166 Since reservation requests are initiated by each receiver, to make 167 sure the reservation request messages from a receiver follow exactly 168 the reverse routes of the data traffic from the sender(s), RSVP must 169 establish a sink tree from each receiver to all senders to forward 170 reservation messages. This is achieved by two-pass signaling message 171 (Path and Resv) exchange process. Besides, to effectively signal QoS 172 to the network, Path messages carry traffic characteristic 173 information (Sender_TSpec) as well as network capability information 174 gathered (ADSpec), while a Resv message carries QoS information 175 (FlowSpec, which includes TSpec and RSpec) requested by the receiver. 176 FlowSpecs should be merged when a Resv message is received by an RSVP 177 router where multicast delivery replicates data packets. 179 2.4 State Management in Routers 181 Each RSVP router uses a Path state to maintain a table of Logical 182 Interface Handle (LIH, the outgoing interface of the previous RSVP 183 hop), previous RSVP hop address (PHOP, used to route the Resv 184 messages hop-by-hop in the reverse direction) and TSpec information 185 for each multicast session. An RSVP router also uses a Resv state to 186 maintain next RSVP hop address (NHOP, used to distinguish its route 187 from other multicast session) and FlowSpec. These states are "soft" 188 which will be time out, unless they are refreshed by the modified or 189 the same Path/Resv message as the first ones. 191 2.5 Error Handling 193 Path errors are simple, because whenever a PathErr message is 194 created, it will be just sent back to the sender. 196 For reservation errors (e.g., admission control fails), a ResvErr 197 message should be reported to all of the responsible receivers. 198 Furthermore, it may result in "killer problems", i.e., if the path 199 towards the source has sufficient resources for the smaller of the 200 reservations but not for the merged request for the multicast, then 201 the effect of merging can be to deny reservations to both. 202 Therefore, the processing of ResvErr messages in RSVPv1 is rather 203 complex. 205 2.6 Non-RSVP Region Handling 207 A subsequent problem due to RSVP two-pass signaling is illustrated in 208 [7], where asymmetric routing for Path and Resv messages in a non- 209 RSVP region can result in a Resv message arriving at a wrong 210 interface of the previous RSVP hop (in the Path direction). To solve 211 this, a LIH is stored in the Path state at next RSVP hop and directs 212 a subsequent Resv message to be forwarded to the previous RSVP hop, 213 then an appropriate reservation can be made to the right interface. 215 3. Removing Multicast in RSVP 217 This section analysis how RSVP would look like if removing its 218 multicast capabilities and supporting only (1:1) unicast. For the 219 convenience of the following discussion, the abbreviation "RSVPw/oMC" 220 is used to stand for the possible feature set by removing multicast 221 in RSVP(v1). 223 Like in RSVPv1, the soft-state mechanism would still be interesting 224 to be used in RSVPw/oMC; QoS signaling in the RSVPw/oMC is also 225 separated from routing in routers; the data flow definition can be 226 the same (i.e., consists of a session = and 227 a filter spec = ). 229 However, RSVPw/oMC will bring a number of simplifications to RSVPv1. 230 In the following paragraphs, these features are briefly described. 231 Descriptions on other aspect of RSVPw/oMC can be found in subsequent 232 sections of this document. 234 3.1 No Reservation Styles 236 Styles in RSVPv1 are used for specifying the sender set for a 237 reservation request and whether these senders share a single 238 reservation. In RSVPw/oMC a receiver has only one sender, therefore 239 styles are not needed any more. Therefore all related burden like 240 merging are released from RSVPw/oMC. 242 3.2 Sender-Initiated Reservation 244 Unlike in RSVPv1, it is not necessary for RSVPw/oMC to be receiver- 245 initiated, because there is only one receiver, and no merging is 246 necessary from the receiver to the sender. In fact, for unicast 247 sessions, a sender typically does know its QoS requirement (maybe via 248 higher layer) and data traffic charateristics, and since there is a 249 need for QoS signaling in a quick way, it would be desireable to be 250 sender-initiated. 252 3.3 Path One-Way Signaling Message for Reservation 254 In RSVPw/oMC, Path and Resv two-pass message exchange would be 255 unnecessary, since no sink-tree is needed for a unicast session. 256 Instead, one-way (Path message) would suffice for setting-up the 257 reservation for a sender's session. On the other hand, to give the 258 sender a chance to see whether and how his reservation request has 259 been fulfiled, an acknowledge message (Ack/NAck) still is beneficial. 260 Therefore, the needed message types in RSVPw/oMC would be: 262 Path: for one-way reservation and state refreshment. This message 263 in fact takes both responsibilities of Path and Resv messages 264 in RSVPv1; the actual reverse directional Resv message in 265 RSVPv1 is no longer necessary; 267 PathErr: for reporting errors in processing Path messages. 269 PathTear: for tear down of Path state. PathTear message is sent 270 by the sender towards the receiver or the IP address where the 271 Path reservation request was rejected to explicitly delete or 272 adapt reservation states; 274 (N)Ack: indicating whether a reservation request is accepted (Ack 275 message) or rejected (NAck). The NAck message shares the same 276 type as the Ack message, but the IP address where the Path 277 reservation is rejected can be included. This provides the 278 sender / higher layer a flexibility in deciding whether to 279 still use the reserved segment for its session, or modify / 280 release the reserved resources. 282 It is further possible to simplify and optimize traffic description 283 and QoS specification by using a "QoS profile (with acceptable and 284 desired QoS level)". To support different QoS provisioning 285 techniques and optimize for the one-way signaling, the FlowSpec in 286 Resv messages and the Sender_TSpec/ADSpec in Path messages of RSVPv1 287 could be unified to a "QoS profile", e.g., as defined in [4]. In the 288 QoS profile of a Path message, the sender can state its desired QoS 289 and (minimally) acceptable QoS, as well as its traffic 290 characteristics (this allows the routers a flexibility to dynamically 291 adapt its reservation in dynamic environments). A QoS profile with 292 actually reserved QoS information can be attached in the Ack message. 294 3.4 Simpler State Management in Routers 296 In RSVPw/oMC, there is no need to keep two states in routers: Path 297 state and Resv state. Instead, just one Path state created by the 298 Path message would be sufficient for RSVPw/oMC QoS signaling. 299 Furthermore, no NHOP/PHOP is needed in the Path state, since the QoS 300 signaling message (Path) is sent one-way from the sender towards the 301 unicast receiver. Finally, hop-by-hop refreshes are simpler since 302 Path/Resv refreshment messages neither need to be distributed towards 303 the multiple receivers/senders nor need to be merged. 305 3.5 Simplified Error Handling 307 Although there still are a few possibilities of error sources in 308 RSVPw/oMC, most of the issues like killer problems become rather 309 easier to handle since: (1) there is no need to merge states for 310 multicast sessions in the RSVP routers, so the number of possible 311 error source decreases; (2) the error reports can be simply returned 312 back to the unicast sender. 314 3.6 Impact on Non-RSVP Region Problem 316 Since the Path message is used for one-way QoS signaling, while in 317 the reverse direction a QoS signaling function is not needed, the 318 problem described in Section 2.6 would disappear in RSVPw/oMC. As a 319 result the LIH information is not needed in the Path states. 321 4. Removing Multicast in Some RSVP Extensions 323 RSVP has been extended in various ways to provide better scalability 324 and usefulness in certain scenarios. In this section we analysis how 325 removing multicast impacts two important RSVP extensions: proxy and 326 aggregation. 328 4.1 Proxy 330 In cases where RSVP cannot be transported end-to-end, an RSVP proxy 331 [6] provides a means to originate or receive RSVP messages on behalf 332 of the end node(s), so that applications may still benefit from 333 reservations that are not truly end-to-end. Removing multicast in 334 principle would also apply to the RSVP proxy scheme. 336 An RSVPw/oMC proxy typically can be placed in the edge of an access 337 network. However, the decision where to place the proxy 338 functionality may be made considering other factors, e.g., as defined 339 in [6]. 341 In RSVPw/oMC, the procedure for incorporating a sender proxy would 342 follow [6]. 344 However, the RSVPv1 receiver proxy [6] should be modified to handle 345 the following RSVPw/oMC messages: 347 Path message. RSVPw/oMC receiver proxy should originate an Ack/ 348 NAck message in response to an incoming Path message, on behalf of 349 the receiver identified by the Path message. 351 PathTear and PathErr messages are treated as in normal RSVPw/oMC. 353 4.2 Aggregation 355 RSVPw/oMC can make use of aggregation in a simpler way compared to 356 RSVPv1. Possible changes to current RSVP aggregation techniques are 357 described below. 359 The aggregator needs to change the protocol identifier of (e2e) RSVP 360 messages into RSVP_e2e_ignore and decide which aggregate flow should 361 the microflow be mapped into (e2ePath-->Path_Aggr per the processing 362 for Resv message in [11]), and takes the (RSVPv1 deaggregator's) 363 responsibility of ensuring that there are sufficient resources 364 reserved within the aggregation region to support the new e2e 365 session. If there are not sufficient resources, a new/existing 366 aggregated reservation should be created/readjusted by a Path_Aggr 367 message from the aggregator towards deaggregator, and returned with 368 an Ack/NAck from the deaggregator or an interior RSVP router. Upon 369 receipt of a Path_Aggr message, the interior routers decides whether 370 to forward it on (when the reservation request is fulfiled) or return 371 a NAck message towards the aggregator. If up to the deaggregator the 372 aggregated reservation request is fulfiled, it acknowledges the 373 aggregator with an Ack message and change the RSVP_e2e_ignore back to 374 e2e Path. Upon receipt of an e2e Ack/NAck, a deaggregator now only 375 needs to map the aggregated reservation to micro-reservations 376 according to its policy. The Path states in interior routers of the 377 aggregate region are maintained in either on-demand or in a more 378 static, statistical way. 380 By RSVPw/oMC, when a Path message travels across an aggregation 381 region, aggregation is much easier since for each aggregator, there 382 is only one deaggregators. Hence, the challenges of complicated 383 multicast processing described in [11] do not exist any longer. 385 5. Benefits of Removing Multicast in RSVP 387 According to the discussion above, RSVPw/oMC potentially has a number 388 of advantages over RSVPv1: 390 Reduction in reservation set-up time. Because RSVPw/oMC does not 391 need a reverse e2e Resv message after an e2e Path message, the 392 reservation set-up time will be one-pass less than in RSVPv1. 394 Reduction of state in routers. There is only one Path state for a 395 session; the PHOP/NHOP/LIH information is not needed. 397 Reduction in processing overhead due to (1) unified QoS profile, 398 (2) no need to merge for multicast session and (3) simpler 399 handling of error and non-RSVP regions. 401 6. Security Aspect 403 By removing multicast support from RSVP, message processing is 404 simplified as explained throughout this document. However, there is 405 little room for optimization in security aspect. Integrity and 406 replay protection of RSVP signaling messages as offered by RFC2747 407 [10] is still required to provide security on a hop-by-hop basis. 408 Additionally, the integrity handshake mechanism used for recovering 409 from host or router crash to offer sequence number resynchronization 410 is required. In order to support policy based admission control and 411 authentication of the user via Kerberos, digital signature or plain- 412 text credentials the objects described in [12] have to be present. 413 Multicast processing of the policy locator inside the POLICY_DATA 414 object can be simplified in such a way that the policy locator is 415 copied from the received to the new message. The same procedure has 416 to be applied for the AUTH_DATA object which is also left unchanged 417 and forwarded (i.e. copied to the new RSVP message). 419 Section 7 of [10] states that in the multicast case all receivers 420 must share a single key with the Kerberos Authentication Server (i.e. 421 a single Kerberos principal is used). Removing multicast allows 422 avoiding the case where all receivers must share a single key. 424 Whether it is possible to simplify processing of POLICY_DATA objects 425 altogether needs further investigation. 427 7. Concluding Remarks 429 This draft analyses ingredients of RSVP Version 1 which are 430 influenced by multicast. We find the following ingredients may not 431 be needed or can be simplified if multicast is not supported: two- 432 pass (Path and Resv), receiver-initiated reservation; complex 433 presentation and operation for signaled information and state 434 management; reservation styles. Also, complexity in dealing with 435 hop-by-hop refreshes, non-RSVP regions and errors would be largely 436 reduced by removing multicast from RSVP. We find that removing 437 multicast capability from RSVP will make it and its extensions on 438 proxy aggregation considerably more light-weight. 440 8. Acknowledgement 442 The authors would like to thank Mehmet Ersue and Holger Karl for 443 their comments to this draft. 445 References 447 [1] Brunner, M., "Requirements for QoS Signaling Protocols", draft- 448 ietf-nsis-req-02 (work in progress), May 2002. 450 [2] Hancock, R. and et al, "Towards a Framework for QoS Signaling 451 in the Internet", draft-hancock-nsis-framework-00 (work in 452 progress), Feb 2002. 454 [3] De Meer, H. and et al, "Analysis of Existing QoS Solutions", 455 draft-demeer-nsis-analysis-01 (work in progress), May 2002. 457 [4] Westphal, C. and et al, "Context Relocation of QoS Parameters 458 in IP Networks", draft-westphal-seamoby-qos-relocate-00 (work 459 in progress), Jul 2001. 461 [5] Braden, B. and B. Lindell, "A Two-Level Architecture for 462 Internet Signaling", draft-braden-2level-signal-arch-00 (work 463 in progress), Nov 2001. 465 [6] Bernet, Y., Elfassy, N., Gai, S. and D. Dutt, "RSVP Proxy", 466 draft-ietf-rsvp-proxy-03 (work in progress), Mar 2002. 468 [7] Braden, R., Estrin, D., Berson, S., Herzog, S. and D. Zappala, 469 "The Design of the RSVP Protocol", ISI Final Technical Report, 470 available at http://www.isi.edu/div7/rsvp/pub.html, Jul 1996. 472 [8] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource 473 ReSerVation Protocol (RSVP) -- Version 1 Functional 474 Specification", RFC 2205, Sep 1997. 476 [9] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 477 Handley, M. and V. Jacobson, "Protocol Independent Multicast- 478 Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, Jun 479 1998. 481 [10] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic 482 Authentication", RFC 2747, Jan 2000. 484 [11] Baker, F., Iturralde, C., Faucheur, F. and B. Davie, 485 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 486 Sep 2001. 488 [12] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 489 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 490 3182, Oct 2001. 492 Authors' Addresses 494 Xiaoming Fu 495 Technical University Berlin 496 Sekr. FT 5-2, Einsteinufer 25 497 Berlin 10587 498 Germany 500 Phone: +49-30-314-23827 501 EMail: fu@ee.tu-berlin.de 503 Cornelia Kappler 504 Siemens AG 505 Siemensdamm 62 506 Berlin 13623 507 Germany 509 Phone: +49-30-386-32894 510 EMail: Cornelia.Kappler@icn.siemens.de 512 Hannes Tschofenig 513 Siemens AG 514 Otto-Hahn-Ring 6 515 Munich 81739 516 Germany 518 Phone: +49-89-636-40390 519 EMail: Hannes.Tschofenig@mchp.siemens.de 521 Full Copyright Statement 523 Copyright (C) The Internet Society (2002). All Rights Reserved. 525 This document and translations of it may be copied and furnished to 526 others, and derivative works that comment on or otherwise explain it 527 or assist in its implementation may be prepared, copied, published 528 and distributed, in whole or in part, without restriction of any 529 kind, provided that the above copyright notice and this paragraph are 530 included on all such copies and derivative works. However, this 531 document itself may not be modified in any way, such as by removing 532 the copyright notice or references to the Internet Society or other 533 Internet organizations, except as needed for the purpose of 534 developing Internet standards in which case the procedures for 535 copyrights defined in the Internet Standards process must be 536 followed, or as required to translate it into languages other than 537 English. 539 The limited permissions granted above are perpetual and will not be 540 revoked by the Internet Society or its successors or assigns. 542 This document and the information contained herein is provided on an 543 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 544 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 545 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 547 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Acknowledgement 551 Funding for the RFC Editor function is currently provided by the 552 Internet Society.