From nsis-admin@ietf.org Fri Apr 6 15:55:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18894; Fri, 6 Apr 2001 15:55:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17534; Fri, 6 Apr 2001 15:55:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17524 for ; Fri, 6 Apr 2001 15:55:40 -0400 (EDT) Received: from cnri.reston.va.us (cnri.reston.va.us [132.151.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18891 for ; Fri, 6 Apr 2001 15:55:40 -0400 (EDT) Received: from action-nt.cnri.reston.va.us (action-nt [132.151.1.91]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id PAA04860 for ; Fri, 6 Apr 2001 15:55:39 -0400 (EDT) Date: Fri, 6 Apr 2001 14:58:35 -0500 (Eastern Standard Time) From: Stanley Weilnau To: nsis@ietf.org Message-ID: X-X-Sender: sweilnau@mailbox.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [NSIS] Test message Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Delete me . _______________________________________________ nsis mailing list nsis@ietf.org http://www.ietf.org/mailman/listinfo/nsis From nsis-admin@ietf.org Mon Apr 16 11:52:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07162; Mon, 16 Apr 2001 11:52:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00517; Mon, 16 Apr 2001 11:52:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29910 for ; Mon, 16 Apr 2001 11:22:31 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06174; Mon, 16 Apr 2001 11:22:30 -0400 (EDT) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id LAA00252; Mon, 16 Apr 2001 11:20:40 -0400 (EDT) Posted-Date: Mon, 16 Apr 2001 11:25:32 -0400 Message-Id: <10104161525.AA00810@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 16 Apr 01 11:25:33 EDT To: minutes@ietf.org Cc: nsis@ietf.org Reply-To: mankin@isi.edu Date: Mon, 16 Apr 2001 11:25:32 -0400 From: Allison Mankin Subject: [NSIS] NSIS BOF Minutes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org BOF Minutes: Next Steps in Signaling The Transport Area Directors held a Next Steps in Signaling birds of a feather session during the 50th IETF meeting in Minneapolis, Minnesota. The aim of the session was to garner an initial set of requirements for a next generation Internet signaling protocol. Allison Mankin was the chair of the BOF and introduced the BOF topic and format. A number of individuals were asked to express one requirement for signaling in the Internet that they have a unique perspective on. After the invited speakers were done the microphone was opened for additional requirements. Following are summeries of what each speaker had to say. Jon Crowcroft Signaling for QoS and path setup must interact with routing. You cannot layer signaling on routing or routing on signaling. We have L2 mechanisms for signaling but no routing, and L3 mechanisms for routing, but no signaling. So we must think recursively about planning and topology. Bruce Davie We need better support for Qos, specifically, for voice applications. 2 examples: (1) Call-waiting support: you would like to only have to reserve *one* set of resources, since you can only talk to one person at a time. RSVP can't do that today (2) You might (in fact, probably would) like to *request* resources before dialing, but not but not actually use those resources until the call is answered. Christian Huitema I'm not a believer in signaling, especially in the core. Concentrate signaling where it is most useful: in the access (last but one hop in network) Today, in the access loop the outbound (sending) direction is already under the user's control. But the other direction is not, and this creates problems sometimes (e.g. denial-of-service). Specifically, a receiver should be able to control what it RECEIVES from the network, and it should be able to do this without having to cooperate with the sender. This is important for handling Denial-of- Service attacks. Georgios Karagiannis Need to introduce IP based transport in mobile access networks. Must support resource reservation signaling that take into account network and radio characteristics in 2G and 3G networks. Examples are bi- directional reservation, edge to edge, reservations, scalability, unicast transmission, and efficient bandwidth utilization to minimize transmission costs. Note that radio access may be very delay sensitive even if the application itself is NOT delay sensitive. James Kempf Radio access networks - air is expensive. Optimize by using less bandwidth and more (for example) CPU cycles. Whatever the signaling protocol is, it must be very efficient for mobility. Providers pay big $$ for the airwaves, they don't want to use it for signaling, but for user data. Best: do the signaling through the backbone, and not over the air if possible. The signaling must be efficient for mobility to minimize signaling while moving from area to area. Mobility signalling should be directly coupled to the traffic. Kireeti Kompella From the Sub-IP point of view the two biggest requirements are for fast notification of errors in a previously set up path and fast rerouting of paths. Rajiv Koodli When a mobile node changes its IP point of attachment, the path that packets take will change. Nodes in new path may need to be signaled. Any mobility-aware signaling protocol should be able to make use of intrinsic IP mobility signaling. Any such protocol must limit signaling to only those parts of the network that are affected. Ping Pan The real scalability problem is "manageability": - - need to shrink the number of reservations to be managed; - - need to avoid manual configuration; - - need to interface with policy and accounting; - - need good measurements and instrumentation. This implies that no "manual configuration", a smaller number of states, the use of policy, and having good measurement instrumentation are the requirements for the new signaling protocol. Brian Rosen There is a need to support signaling for large numbers of call reservations where the bandwidth for signaling is restricted. Signaling for 2000-3000 calls per second using end-to-end signaling over low-bit-rate hops is one such requirement. We need resource reservations to support audio and video pipes. The network has multiple millions of end points and is bandwidth-limited at the edges. The reservations have to be hard end-to-end reservations. Henning Schulzrinne We might want a new signaling protocol to do the sorts of things MPLS is being used for, such as setting up paths independent of what routing says on the global scale. Signaling state should be able to dip into the path of IP packets and dip out. The end system should not have to be involved. We need the ability to transparently carry objects such as pricing detail without the IETF worrying about business policies outside it's control. Melinda Shore So any signaling protocol we design needs to be able to handle signaling to or from a middleboxes in transport layer e.g. firewalls and NATs. Either the middlebox needs to be aware of applications or vice versa. We've been doing the former -- it doesn't scale, things break, etc. Data and control paths are separated in apps -- people know this. But in many cases the control path is mediated by some third party (e.g. an ALG or a Call Center or something). Whatever we do here needs to be aware of that fact. Mark Stevens Rather than designing new signaling protocols, what we really need to do is better define the interfaces for existing protocols. What has been seen so far is the requirement for real time feedback into network that runs today without any process control, flat out. We should think about defining and developing descriptions of interfaces, starting with underlying data that needs to be manipulated in this network Michael Thomas A good QoS signaling protocol for a mobile environment should exhibit good local convergence after topology changes. Also, there is a need to understand how Cross-Realm Admission Control / Policy should work. Dan Grossman There exists a rich, multidimensional space at performance parameters, security, and "cost" (proxy for resources). There needs to be a way to express this tradeoff in a reasonable way that conveys what both sides need (assuming that the resources are not in infinite supply, so that cost is not a consideration, so that billing can be more intelligent. Bala Balagopan I am at a loss to understand what is happening in this BOF. Are we planning to design a super protocol that satisfies all the varying requirements? My foremost requirement is to clean up RSVP because it is used for purposes other than what it was defined for. I support Kireeti's requirement of a lightweight protocol. Kwok Chan Signaling protocols have different time scale requirements (milliseconds, microseconds, seconds etc). Knowing the time scale requirement may solve the problem by enabling dynamic policies that can be very fast, minimize complexity and are centrally controlled. Ludier A good requirement is the development of a generic QoS mechanism similar to RSVP which is quite generic, unlike Intserv, which has two specific QoS mechanisms. Generic service will rely only on "frame" and is protocol agnostic. John Loughney Privacy and anonymity need to be taken into account. We should be able to deal with multiple "presentations" of an individual. Mark Townsley Close to what the previous speaker said but not exactly: ensure security, integrity of packets. Must be able to signal the security requirements for packets Ping Pan We need to be flexible in our approach. There is no one protocol that is right for all purposes. For example, a signaling protocol involving an end user must be very fast. But reliability/redundancy issues are more important for a signaling protocol between backbone routers. Matt Holdridge The tradeoff is between stateful vs stateless protocols. We don't have to argue for stateful as we know the cons. We do have the capability of building stateless protocols - and that should be the requirement. Bob Braden I've been thinking about the RSVP mess, and have ideas that to do with implementations, not requirements. It may be useful to learn from experience of RSVP to have a proper interpretation of requirements. Jim Kempf There is a need for simple authentication If you look at signaling in RSVP/mobility, it's not good. But if you look at what's required to do authentication in RSVP, it's even worse. We need "extremely lightweight authentication." Melinda Shore Concealing the network topology from the end user is nice, if/when it is possible. But midcom requires exposing network topology to apps. We need on-the-path signaling, without exposing topology to the edge host. Henning Schulzrinne We need both sender-oriented and receiver-oriented protocols. We need both soft state and hard state protocols, and protocols with in- between state (e.g., "ice cream state", that starts off hard and softens over time), especially. for voice over IP. Jon Crowcroft: Don't fix signaling protocols via new requirements, but give a new direction in signaling requirements. PNNI specifications are excellently written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing RSVP until you have read all these protocols. We should not reinvent the wheel and waste the time of the IETF. Tim Shepherd: The Internet, or rather the IP networking technology, has come to dominate because of its superiority in one dimension of quality of service over other competing technologies: support of spontaneity. A requirement for signaling, is that it not destroy the good quality of service that raw IP networks already have. I.e., it must still be possible for things to be done between consenting end systems without requiring them to first have a conversation with the network about their intentions. John Vollbrecht: We need auditability and trackability. Yves T'Joens There should be a strict decoupling between protocol and the information it is carrying. Aaron Falk Signaling should work over all kinds of networks, e.g., high error networks, asymmetric networks, slow networks, broadcast networks, unidirectional networks. Charlie Perkins We need to be able to do secure and reliable signaling for anycast groups. Acknowledgements Thanks to the following people who sent us their notes of the meeting. They have been melded together to produce this memo: Steve Berson, Bob Braden, Ken Calvert, John Loughney, Ellen L. Hahne, Matt Holdrege, Ananth Nagaraja, and Jarno Rajahalme ------- End of Forwarded Message _______________________________________________ nsis mailing list nsis@ietf.org http://www.ietf.org/mailman/listinfo/nsis From nsis-admin@ietf.org Tue Apr 17 21:42:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20486; Tue, 17 Apr 2001 21:42:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08988; Tue, 17 Apr 2001 21:42:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00384 for ; Mon, 16 Apr 2001 11:42:56 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06875; Mon, 16 Apr 2001 11:42:55 -0400 (EDT) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id LAA00584; Mon, 16 Apr 2001 11:42:46 -0400 (EDT) Posted-Date: Mon, 16 Apr 2001 11:47:37 -0400 Message-Id: <10104161547.AA00857@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 16 Apr 01 11:47:38 EDT To: minutes@ietf.org Cc: nsis@ietf.org, sob@harvard.edu Reply-To: mankin@isi.edu Date: Mon, 16 Apr 2001 11:47:37 -0400 From: Allison Mankin Subject: [NSIS] Revised NSIS minutes (including outline of slides) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org BOF Minutes: Next Steps in Signaling (NSIS) The Transport Area Directors held a Next Steps in Signaling birds of a feather session during the 50th IETF meeting in Minneapolis, Minnesota. The aim of the session was to garner an initial set of requirements for a next generation Internet signaling protocol. Allison Mankin was the chair of the BOF and introduced the BOF topic and format. The slides used in the intro are included (in outline form) at the end of these minutes. A number of individuals were asked to express one requirement for signaling in the Internet that they have a unique perspective on. After the invited speakers were done the microphone was opened for additional requirements. Following are summeries of what each speaker had to say. Jon Crowcroft Signaling for QoS and path setup must interact with routing. You cannot layer signaling on routing or routing on signaling. We have L2 mechanisms for signaling but no routing, and L3 mechanisms for routing, but no signaling. So we must think recursively about planning and topology. Bruce Davie We need better support for Qos, specifically, for voice applications. 2 examples: (1) Call-waiting support: you would like to only have to reserve *one* set of resources, since you can only talk to one person at a time. RSVP can't do that today (2) You might (in fact, probably would) like to *request* resources before dialing, but not but not actually use those resources until the call is answered. Christian Huitema I'm not a believer in signaling, especially in the core. Concentrate signaling where it is most useful: in the access (last but one hop in network) Today, in the access loop the outbound (sending) direction is already under the user's control. But the other direction is not, and this creates problems sometimes (e.g. denial-of-service). Specifically, a receiver should be able to control what it RECEIVES from the network, and it should be able to do this without having to cooperate with the sender. This is important for handling Denial-of- Service attacks. Georgios Karagiannis Need to introduce IP based transport in mobile access networks. Must support resource reservation signaling that take into account network and radio characteristics in 2G and 3G networks. Examples are bi- directional reservation, edge to edge, reservations, scalability, unicast transmission, and efficient bandwidth utilization to minimize transmission costs. Note that radio access may be very delay sensitive even if the application itself is NOT delay sensitive. James Kempf Radio access networks - air is expensive. Optimize by using less bandwidth and more (for example) CPU cycles. Whatever the signaling protocol is, it must be very efficient for mobility. Providers pay big $$ for the airwaves, they don't want to use it for signaling, but for user data. Best: do the signaling through the backbone, and not over the air if possible. The signaling must be efficient for mobility to minimize signaling while moving from area to area. Mobility signalling should be directly coupled to the traffic. Kireeti Kompella From the Sub-IP point of view the two biggest requirements are for fast notification of errors in a previously set up path and fast rerouting of paths. Rajiv Koodli When a mobile node changes its IP point of attachment, the path that packets take will change. Nodes in new path may need to be signaled. Any mobility-aware signaling protocol should be able to make use of intrinsic IP mobility signaling. Any such protocol must limit signaling to only those parts of the network that are affected. Ping Pan The real scalability problem is "manageability": - need to shrink the number of reservations to be managed; - need to avoid manual configuration; - need to interface with policy and accounting; - need good measurements and instrumentation. This implies that no "manual configuration", a smaller number of states, the use of policy, and having good measurement instrumentation are the requirements for the new signaling protocol. Brian Rosen There is a need to support signaling for large numbers of call reservations where the bandwidth for signaling is restricted. Signaling for 2000-3000 calls per second using end-to-end signaling over low-bit-rate hops is one such requirement. We need resource reservations to support audio and video pipes. The network has multiple millions of end points and is bandwidth-limited at the edges. The reservations have to be hard end-to-end reservations. Henning Schulzrinne We might want a new signaling protocol to do the sorts of things MPLS is being used for, such as setting up paths independent of what routing says on the global scale. Signaling state should be able to dip into the path of IP packets and dip out. The end system should not have to be involved. We need the ability to transparently carry objects such as pricing detail without the IETF worrying about business policies outside it's control. Melinda Shore So any signaling protocol we design needs to be able to handle signaling to or from a middleboxes in transport layer e.g. firewalls and NATs. Either the middlebox needs to be aware of applications or vice versa. We've been doing the former -- it doesn't scale, things break, etc. Data and control paths are separated in apps -- people know this. But in many cases the control path is mediated by some third party (e.g. an ALG or a Call Center or something). Whatever we do here needs to be aware of that fact. Mark Stevens Rather than designing new signaling protocols, what we really need to do is better define the interfaces for existing protocols. What has been seen so far is the requirement for real time feedback into network that runs today without any process control, flat out. We should think about defining and developing descriptions of interfaces, starting with underlying data that needs to be manipulated in this network Michael Thomas A good QoS signaling protocol for a mobile environment should exhibit good local convergence after topology changes. Also, there is a need to understand how Cross-Realm Admission Control / Policy should work. The above were "non-talks" prepared by the speakers with a day or two of notice. We thank folks for their collaboration. The following are additional "non-talks" offered inpromptu, and we thank these folks as well. Dan Grossman There exists a rich, multidimensional space at performance parameters, security, and "cost" (proxy for resources). There needs to be a way to express this tradeoff in a reasonable way that conveys what both sides need (assuming that the resources are not in infinite supply, so that cost is not a consideration, so that billing can be more intelligent. Bala Balagopan I am at a loss to understand what is happening in this BOF. Are we planning to design a super protocol that satisfies all the varying requirements? My foremost requirement is to clean up RSVP because it is used for purposes other than what it was defined for. I support Kireeti's requirement of a lightweight protocol. Kwok Chan Signaling protocols have different time scale requirements (milliseconds, microseconds, seconds etc). Knowing the time scale requirement may solve the problem by enabling dynamic policies that can be very fast, minimize complexity and are centrally controlled. Ludier A good requirement is the development of a generic QoS mechanism similar to RSVP which is quite generic, unlike Intserv, which has two specific QoS mechanisms. Generic service will rely only on "frame" and is protocol agnostic. John Loughney Privacy and anonymity need to be taken into account. We should be able to deal with multiple "presentations" of an individual. Mark Townsley Close to what the previous speaker said but not exactly: ensure security, integrity of packets. Must be able to signal the security requirements for packets Ping Pan We need to be flexible in our approach. There is no one protocol that is right for all purposes. For example, a signaling protocol involving an end user must be very fast. But reliability/redundancy issues are more important for a signaling protocol between backbone routers. Matt Holdredge The tradeoff is between stateful vs stateless protocols. We don't have to argue for stateful as we know the cons. We do have the capability of building stateless protocols - and that should be the requirement. Bob Braden I've been thinking about the RSVP mess, and have ideas that to do with implementations, not requirements. It may be useful to learn from experience of RSVP to have a proper interpretation of requirements. Jim Kempf There is a need for simple authentication If you look at signaling in RSVP/mobility, it's not good. But if you look at what's required to do authentication in RSVP, it's even worse. We need "extremely lightweight authentication." Melinda Shore Concealing the network topology from the end user is nice, if/when it is possible. But midcom requires exposing network topology to apps. We need on-the-path signaling, without exposing topology to the edge host. Henning Schulzrinne We need both sender-oriented and receiver-oriented protocols. We need both soft state and hard state protocols, and protocols with in- between state (e.g., "ice cream state", that starts off hard and softens over time), especially. for voice over IP. Jon Crowcroft: Don't fix signaling protocols via new requirements, but give a new direction in signaling requirements. PNNI specifications are excellently written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing RSVP until you have read all these protocols. We should not reinvent the wheel and waste the time of the IETF. Tim Shepherd: The Internet, or rather the IP networking technology, has come to dominate because of its superiority in one dimension of quality of service over other competing technologies: support of spontaneity. A requirement for signaling, is that it not destroy the good quality of service that raw IP networks already have. I.e., it must still be possible for things to be done between consenting end systems without requiring them to first have a conversation with the network about their intentions. John Vollbrecht: We need auditability and trackability. Yves T'Joens There should be a strict decoupling between protocol and the information it is carrying. Aaron Falk Signaling should work over all kinds of networks, e.g., high error networks, asymmetric networks, slow networks, broadcast networks, unidirectional networks. Charlie Perkins We need to be able to do secure and reliable signaling for anycast groups. Acknowledgements Thanks to the following people who sent us their notes of the meeting. They have been melded together to produce this memo: Steve Berson, Bob Braden, Ken Calvert, John Loughney, Ellen L. Hahne, Matt Holdrege, Ananth Nagaraja, and Jarno Rajahalme Introductory Slides: Next Steps in Signaling BOF - IETF 50 Allison Mankin Transport Co-Area Director Slide 1 Purpose of NSIS BOF Many signaling protocol developments at IETF RSVP (RFC 2205) RSVP core protocol and QoS kids, e.g. Authentication (2347) DCLASS RSVP kids in other fields, e.g. RSVP-TE COPS Slide 2 Purpose (cont) New signaling protocol discussions/developments Both general QoS signaling and RSVP use in mobile Internet Possible signaling protocol use for midcom Extended thinking about signaling in ccamp context Slide 3 Requirements Process WG requirements development often isolated Requirements are gleaned not only from working group discussions but from informal and formal input from other groups (e.g. 3GPP et al) What are overarching requirements? Slide 4 Interpretation of Requirements Can benefit from whole-picture processing Whole-picture helps with scenarios such as: Here are the requirements. Thanks, they're impossible, what can you do with what is possible? The requirements are to use this set of RFCs. Mmm, what requirements are expressed by the technology in that set of RFCs? Etc. Slide 5 This BOF Starts Requirements Gathering Assignment to about a dozen "non-speakers": State a requirement for signaling in the Internet that you have a unique perspective on (e.g. within sub-ip, in wireless, cellular, cable, ssm multicast distribution, content distribution, middle box control, policy as in RAP, as well as commodity QoS). Slide 6 Rules No slides Three minutes only One requirement If your point has been made already, come up with another (you can do it) No endorsement or rebuttal of other non-talks Slide 7 Audience Participation Need reporters (precise notes of the non-talks) Time at end for volunteered non-talks Slide 8 Procedure Name of speaker will be projected (thus enforcing no-slides rule) Three minutes will be enforced No questions during non-talks, only non-talks at the mike after, unless there are none. Understand at least enough requirements (and how many sets) so we can set some groups to developing useful requirements draft(s) _______________________________________________ nsis mailing list nsis@ietf.org http://www.ietf.org/mailman/listinfo/nsis