Network Working Group                                      Scott Bradner
Internet-Draft                                        Harvard University
                                                          Allison Mankin
                                                               July 2001

               Report of the Next Steps in Signaling BOF


1. Status of this Memo

   This document is an Internet-Draft and is in subject to the
   provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   Copyright notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

2. Abstract

   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.  This
   memo is a summary of the input we received during that session.

3. Published NSIS BOF Description

Bradner & Mankin                                                [Page 1]

Internet-Draft           Next Steps in Signaling               July 2001

   "There have been a number of proposals for a new IETF signaling
   protocol which is potentially simpler than RSVP, and that is
   potentially easier to apply to the many uses of signaling beyond
   RSVP's original use in setup of quality of service.  This BOF will
   attempt to get an understanding of the applications for such a
   signaling protocol and to explore the possible alternatives for a new
   effort; both modifying an existing IETF signaling protocol and
   developing a new one will be considered."

4. Session Description

   The session began with comments from a series of people who had been
   specifically invited to speak and then the microphone was opened for
   anyone else who wanted to offer their suggestions.  Each speaker was
   limited to a maximum of 3 minutes although most took less than their
   allotted time.

   The speakers are identified here not to cast blame but instead to
   give credit and to identify who could be tapped for more information
   on a particular suggestion.

5. BOF Introduction (Allison Mankin)

   There are many existing signaling protocols at the IETF
   - RSVP
   - RSVP Core & children for DiffServe
   - RSVP for traffic engineering
   - COPS

   In addition there is work on new signaling protocols
   - General QoS signaling & RSVP in mobile network
   - Possible signaling protocol use for midcom
   - Extending thinking about signaling in ccamp context

   IETF Requirements Process
   - WG requirements development often isolated
   - Requirements are gleaned not only from working group discussions &
     from other groups
   - Missing is an understanding of what are the overarching
   - Interpretation of requirements can benefit from whole picture
   - e.g. some requirements turn out to be for essentially faster-than-
     light signaling.  ti -2 - some requirements say "conform to these
     RFCs" -- that's not what we want - we want to know what the actual
     needs are

Bradner & Mankin                                                [Page 2]

Internet-Draft           Next Steps in Signaling               July 2001

   Signaling" has different meanings depending on context. We won't
   define signaling. Please listen closely to see how people presenting
   define their requirements and try to understand what they mean by

   This BOF starts the requirements gathering process for future IETF
   work on signaling.

   A number of individuals were asked to express one requirement for
   signaling in the Internet that they have a unique perspective on.

6. Invited Speakers

6.1  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.

6.2 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.

6.3 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.

6.4 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.

Bradner & Mankin                                                [Page 3]

Internet-Draft           Next Steps in Signaling               July 2001

6.5 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.

6.6 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.

6.7 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.

6.8 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.

6.9 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.

6.10 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

Bradner & Mankin                                                [Page 4]

Internet-Draft           Next Steps in Signaling               July 2001

   objects such as pricing detail without the IETF worrying about
   business policies outside it's control.

6.11 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.

6.12 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

6.13 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.

7. Ad Hoc Speakers

7.1 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.

7.2 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.

7.3 Kwok Chan

Bradner & Mankin                                                [Page 5]

Internet-Draft           Next Steps in Signaling               July 2001

   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.

7.4 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.

7.5 John Loughney
   Privacy and anonymity need to be taken into account.  We should be
   able to deal with multiple "presentations" of an individual.

7.6 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

7.7 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

7.8 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

7.9 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

7.10 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."

7.11 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.

Bradner & Mankin                                                [Page 6]

Internet-Draft           Next Steps in Signaling               July 2001

   We need on-the-path signaling, without exposing topology to the edge

7.12 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.

7.13 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.

7.14 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.

7.15 John Vollbrecht:
   We need auditability and trackability.

7.16 Yves T'Joens
   There should be a strict decoupling between protocol and the
   information it is carrying.

7.17 Aaron Falk
   Signaling should work over all kinds of networks, e.g., high error
   networks, asymmetric networks, slow networks, broadcast networks,
   unidirectional networks.

7.12 Charlie Perkins
   We need to be able to do secure and reliable signaling for anycast

8. Additional Requirements received in Email

8.1 John Loughney
   Need simplicity. At the end of the day, a simple protocol stands the
   chance of succeeding better than a complex one.

Bradner & Mankin                                                [Page 7]

Internet-Draft           Next Steps in Signaling               July 2001

8.2 Ken Calvert
   I'm looking at signaling requirements for GRA, and of course we'd
   like not to reinvent any wheels. I'd like to echo Henning's
   suggestion to stay "approach-neutral" as far as possible.  It'd be
   very nice for GRA if the protocol could be neutral in regards to
   sender/receiver orientation.

8.3 Kathleen Nichols
   I realized in NSIS that there is something that I find very
   concerning about the "requirement" of fine-grained telephony type
   control in an "IP signaling protocol". It's one thing to say "how can
   we put voice services onto the Internet and what would that look like
   and what (minimally) would it take?"  It's quite another to say "how
   can we make the Internet support all the traditional telco/telephony
   services?" I suspect the latter is quite hard while the former is
   quite interesting.

9.0 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. Sorry if we accidentally
   omitted anyone, we had so many eager note takers.

10.0 Security Considerations

   An important requirement for any next generation signaling protocol
   will be that its operation must be secure in the face of malicious
   attacks and attempts to disrupt, hijack or steal the services
   signaled by the protocol.

11.0 Editors' Addresses

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA 02138

   Phone: +1-617-495-3864

   Allison Mankin
   4350 N. Fairfax Drive, Suite 620

Bradner & Mankin                                                [Page 8]

Internet-Draft           Next Steps in Signaling               July 2001

   Arlington VA 22203

   Phone: +1-703-812-3706

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Bradner & Mankin                                                [Page 9]