idnits 2.17.1 draft-bradner-nsis-bof-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction 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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 145 has weird spacing: '...'t want to us...' == Line 232 has weird spacing: '...is used for p...' -- 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 (July 2001) is 8320 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Internet-Draft Harvard University 4 Allison Mankin 5 USC/ISI 6 July 2001 8 Report of the Next Steps in Signaling BOF 10 draft-bradner-nsis-bof-00.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in subject to the 15 provisions of Section 10 of RFC 2026. 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 28 http://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 Copyright notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 2. Abstract 39 The Transport Area Directors held a Next Steps in Signaling birds of 40 a feather session during the 50th IETF meeting in Minneapolis, 41 Minnesota. The aim of the session was to garner an initial set of 42 requirements for a next generation Internet signaling protocol. This 43 memo is a summary of the input we received during that session. 45 3. Published NSIS BOF Description 46 "There have been a number of proposals for a new IETF signaling 47 protocol which is potentially simpler than RSVP, and that is 48 potentially easier to apply to the many uses of signaling beyond 49 RSVP's original use in setup of quality of service. This BOF will 50 attempt to get an understanding of the applications for such a 51 signaling protocol and to explore the possible alternatives for a new 52 effort; both modifying an existing IETF signaling protocol and 53 developing a new one will be considered." 55 4. Session Description 57 The session began with comments from a series of people who had been 58 specifically invited to speak and then the microphone was opened for 59 anyone else who wanted to offer their suggestions. Each speaker was 60 limited to a maximum of 3 minutes although most took less than their 61 allotted time. 63 The speakers are identified here not to cast blame but instead to 64 give credit and to identify who could be tapped for more information 65 on a particular suggestion. 67 5. BOF Introduction (Allison Mankin) 69 There are many existing signaling protocols at the IETF 70 - RSVP 71 - RSVP Core & children for DiffServe 72 - RSVP for traffic engineering 73 - COPS 75 In addition there is work on new signaling protocols 76 - General QoS signaling & RSVP in mobile network 77 - Possible signaling protocol use for midcom 78 - Extending thinking about signaling in ccamp context 80 IETF Requirements Process 81 - WG requirements development often isolated 82 - Requirements are gleaned not only from working group discussions & 83 from other groups 84 - Missing is an understanding of what are the overarching 85 requirements 86 - Interpretation of requirements can benefit from whole picture 87 processing 88 - e.g. some requirements turn out to be for essentially faster-than- 89 light signaling. ti -2 - some requirements say "conform to these 90 RFCs" -- that's not what we want - we want to know what the actual 91 needs are 93 Signaling" has different meanings depending on context. We won't 94 define signaling. Please listen closely to see how people presenting 95 define their requirements and try to understand what they mean by 96 signaling. 98 This BOF starts the requirements gathering process for future IETF 99 work on signaling. 101 A number of individuals were asked to express one requirement for 102 signaling in the Internet that they have a unique perspective on. 104 6. Invited Speakers 106 6.1 Jon Crowcroft 107 Signaling for QoS and path setup must interact with routing. You 108 cannot layer signaling on routing or routing on signaling. We have L2 109 mechanisms for signaling but no routing, and L3 mechanisms for 110 routing, but no signaling. So we must think recursively about 111 planning and topology. 113 6.2 Bruce Davie 114 We need better support for Qos, specifically, for voice applications. 115 2 examples: (1) Call-waiting support: you would like to only have to 116 reserve *one* set of resources, since you can only talk to one person 117 at a time. RSVP can't do that today (2) You might (in fact, probably 118 would) like to *request* resources before dialing, but not but not 119 actually use those resources until the call is answered. 121 6.3 Christian Huitema 122 I'm not a believer in signaling, especially in the core. Concentrate 123 signaling where it is most useful: in the access (last but one hop in 124 network) Today, in the access loop the outbound (sending) direction 125 is already under the user's control. But the other direction is not, 126 and this creates problems sometimes (e.g. denial-of-service). 127 Specifically, a receiver should be able to control what it RECEIVES 128 from the network, and it should be able to do this without having to 129 cooperate with the sender. This is important for handling Denial-of- 130 Service attacks. 132 6.4 Georgios Karagiannis 133 Need to introduce IP based transport in mobile access networks. Must 134 support resource reservation signaling that take into account network 135 and radio characteristics in 2G and 3G networks. Examples are bi- 136 directional reservation, edge to edge, reservations, scalability, 137 unicast transmission, and efficient bandwidth utilization to minimize 138 transmission costs. Note that radio access may be very delay 139 sensitive even if the application itself is NOT delay sensitive. 141 6.5 James Kempf 142 Radio access networks - air is expensive. Optimize by using less 143 bandwidth and more (for example) CPU cycles. Whatever the signaling 144 protocol is, it must be very efficient for mobility. Providers pay 145 big $$ for the airwaves, they don't want to use it for signaling, 146 but for user data. Best: do the signaling through the backbone, and 147 not over the air if possible. The signaling must be efficient for 148 mobility to minimize signaling while moving from area to area. 149 Mobility signalling should be directly coupled to the traffic. 151 6.6 Kireeti Kompella 152 From the Sub-IP point of view the two biggest requirements are for 153 fast notification of errors in a previously set up path and fast 154 rerouting of paths. 156 6.7 Rajiv Koodli 157 When a mobile node changes its IP point of attachment, the path that 158 packets take will change. Nodes in new path may need to be signaled. 159 Any mobility-aware signaling protocol should be able to make use of 160 intrinsic IP mobility signaling. Any such protocol must limit 161 signaling to only those parts of the network that are affected. 163 6.8 Ping Pan 164 The real scalability problem is "manageability": 165 - need to shrink the number of reservations to be managed; 166 - need to avoid manual configuration; 167 - need to interface with policy and accounting; 168 - need good measurements and instrumentation. 170 This implies that no "manual configuration", a smaller number of 171 states, the use of policy, and having good measurement 172 instrumentation are the requirements for the new signaling protocol. 174 6.9 Brian Rosen 175 There is a need to support signaling for large numbers of call 176 reservations where the bandwidth for signaling is restricted. 177 Signaling for 2000-3000 calls per second using end-to-end signaling 178 over low-bit-rate hops is one such requirement. We need resource 179 reservations to support audio and video pipes. The network has 180 multiple millions of end points and is bandwidth-limited at the 181 edges. The reservations have to be hard end-to-end reservations. 183 6.10 Henning Schulzrinne 184 We might want a new signaling protocol to do the sorts of things MPLS 185 is being used for, such as setting up paths independent of what 186 routing says on the global scale. Signaling state should be able to 187 dip into the path of IP packets and dip out. The end system should 188 not have to be involved. We need the ability to transparently carry 189 objects such as pricing detail without the IETF worrying about 190 business policies outside it's control. 192 6.11 Melinda Shore 193 So any signaling protocol we design needs to be able to handle 194 signaling to or from a middleboxes in transport layer e.g. firewalls 195 and NATs. Either the middlebox needs to be aware of applications or 196 vice versa. We've been doing the former -- it doesn't scale, things 197 break, etc. 199 Data and control paths are separated in apps -- people know this. 200 But in many cases the control path is mediated by some third party 201 (e.g. an ALG or a Call Center or something). Whatever we do here 202 needs to be aware of that fact. 204 6.12 Mark Stevens 205 Rather than designing new signaling protocols, what we really need to 206 do is better define the interfaces for existing protocols. What has 207 been seen so far is the requirement for real time feedback into 208 network that runs today without any process control, flat out. We 209 should think about defining and developing descriptions of 210 interfaces, starting with underlying data that needs to be 211 manipulated in this network 213 6.13 Michael Thomas 214 A good QoS signaling protocol for a mobile environment should exhibit 215 good local convergence after topology changes. Also, there is a need 216 to understand how Cross-Realm Admission Control / Policy should work. 218 7. Ad Hoc Speakers 220 7.1 Dan Grossman 221 There exists a rich, multidimensional space at performance 222 parameters, security, and "cost" (proxy for resources). There needs 223 to be a way to express this tradeoff in a reasonable way that conveys 224 what both sides need (assuming that the resources are not in infinite 225 supply, so that cost is not a consideration, so that billing can be 226 more intelligent. 228 7.2 Bala Balagopan 229 I am at a loss to understand what is happening in this BOF. Are we 230 planning to design a super protocol that satisfies all the varying 231 requirements? My foremost requirement is to clean up RSVP because it 232 is used for purposes other than what it was defined for. I support 233 Kireeti's requirement of a lightweight protocol. 235 7.3 Kwok Chan 236 Signaling protocols have different time scale requirements 237 (milliseconds, microseconds, seconds etc). Knowing the time scale 238 requirement may solve the problem by enabling dynamic policies that 239 can be very fast, minimize complexity and are centrally controlled. 241 7.4 Ludier 242 A good requirement is the development of a generic QoS mechanism 243 similar to RSVP which is quite generic, unlike Intserv, which has two 244 specific QoS mechanisms. Generic service will rely only on "frame" 245 and is protocol agnostic. 247 7.5 John Loughney 248 Privacy and anonymity need to be taken into account. We should be 249 able to deal with multiple "presentations" of an individual. 251 7.6 Mark Townsley 252 Close to what the previous speaker said but not exactly: ensure 253 security, integrity of packets. Must be able to signal the security 254 requirements for packets 256 7.7 Ping Pan 257 We need to be flexible in our approach. There is no one protocol 258 that is right for all purposes. For example, a signaling protocol 259 involving an end user must be very fast. But reliability/redundancy 260 issues are more important for a signaling protocol between backbone 261 routers. 263 7.8 Matt Holdridge 264 The tradeoff is between stateful vs stateless protocols. We don't 265 have to argue for stateful as we know the cons. We do have the 266 capability of building stateless protocols - and that should be the 267 requirement. 269 7.9 Bob Braden 270 I've been thinking about the RSVP mess, and have ideas that to do 271 with implementations, not requirements. It may be useful to learn 272 from experience of RSVP to have a proper interpretation of 273 requirements. 275 7.10 Jim Kempf 276 There is a need for simple authentication If you look at signaling in 277 RSVP/mobility, it's not good. But if you look at what's required to 278 do authentication in RSVP, it's even worse. We need "extremely 279 lightweight authentication." 281 7.11 Melinda Shore 282 Concealing the network topology from the end user is nice, if/when it 283 is possible. But midcom requires exposing network topology to apps. 285 We need on-the-path signaling, without exposing topology to the edge 286 host. 288 7.12 Henning Schulzrinne 289 We need both sender-oriented and receiver-oriented protocols. We 290 need both soft state and hard state protocols, and protocols with in- 291 between state (e.g., "ice cream state", that starts off hard and 292 softens over time), especially. for voice over IP. 294 7.13 Jon Crowcroft: 295 Don't fix signaling protocols via new requirements, but give a new 296 direction in signaling requirements. PNNI specifications are 297 excellently written, 3G handoff is excellent, Q.2931 is excellent. 298 Don't start fixing RSVP until you have read all these protocols. We 299 should not reinvent the wheel and waste the time of the IETF. 301 7.14 Tim Shepherd: 302 The Internet, or rather the IP networking technology, has come to 303 dominate because of its superiority in one dimension of quality of 304 service over other competing technologies: support of spontaneity. 305 A requirement for signaling, is that it not destroy the good quality 306 of service that raw IP networks already have. I.e., it must still be 307 possible for things to be done between consenting end systems without 308 requiring them to first have a conversation with the network about 309 their intentions. 311 7.15 John Vollbrecht: 312 We need auditability and trackability. 314 7.16 Yves T'Joens 315 There should be a strict decoupling between protocol and the 316 information it is carrying. 318 7.17 Aaron Falk 319 Signaling should work over all kinds of networks, e.g., high error 320 networks, asymmetric networks, slow networks, broadcast networks, 321 unidirectional networks. 323 7.12 Charlie Perkins 324 We need to be able to do secure and reliable signaling for anycast 325 groups. 327 8. Additional Requirements received in Email 329 8.1 John Loughney 330 Need simplicity. At the end of the day, a simple protocol stands the 331 chance of succeeding better than a complex one. 333 8.2 Ken Calvert 334 I'm looking at signaling requirements for GRA, and of course we'd 335 like not to reinvent any wheels. I'd like to echo Henning's 336 suggestion to stay "approach-neutral" as far as possible. It'd be 337 very nice for GRA if the protocol could be neutral in regards to 338 sender/receiver orientation. 340 8.3 Kathleen Nichols 341 I realized in NSIS that there is something that I find very 342 concerning about the "requirement" of fine-grained telephony type 343 control in an "IP signaling protocol". It's one thing to say "how can 344 we put voice services onto the Internet and what would that look like 345 and what (minimally) would it take?" It's quite another to say "how 346 can we make the Internet support all the traditional telco/telephony 347 services?" I suspect the latter is quite hard while the former is 348 quite interesting. 350 9.0 Acknowledgements 352 Thanks to the following people who sent us their notes of the 353 meeting. They have been melded together to produce this memo: Steve 354 Berson, Bob Braden, Ken Calvert, John Loughney, Ellen L. Hahne, Matt 355 Holdrege, Ananth Nagaraja, and Jarno Rajahalme. Sorry if we accidentally 356 omitted anyone, we had so many eager note takers. 358 10.0 Security Considerations 360 An important requirement for any next generation signaling protocol 361 will be that its operation must be secure in the face of malicious 362 attacks and attempts to disrupt, hijack or steal the services 363 signaled by the protocol. 365 11.0 Editors' Addresses 367 Scott Bradner 368 Harvard University 369 29 Oxford St. 370 Cambridge MA 02138 372 Email: sob@harvard.edu 373 Phone: +1-617-495-3864 375 Allison Mankin 376 USC/ISI 377 4350 N. Fairfax Drive, Suite 620 378 Arlington VA 22203 380 Email: mankin@isi.edu 381 Phone: +1-703-812-3706 383 Full Copyright Statement 385 Copyright (C) The Internet Society (2001). All Rights Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns. 404 This document and the information contained herein is provided on an 405 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 406 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 407 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 408 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 409 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Acknowledgement 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.