Network Working Group Scott Bradner
Internet-Draft Harvard University
Allison Mankin
USC/ISI
July 2001
Report of the Next Steps in Signaling BOF
draft-bradner-nsis-bof-00.txt
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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
requirements
- Interpretation of requirements can benefit from whole picture
processing
- 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
signaling.
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
routers.
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
requirement.
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
requirements.
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
host.
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
groups.
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
Email: sob@harvard.edu
Phone: +1-617-495-3864
Allison Mankin
USC/ISI
4350 N. Fairfax Drive, Suite 620
Bradner & Mankin [Page 8]
Internet-Draft Next Steps in Signaling July 2001
Arlington VA 22203
Email: mankin@isi.edu
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
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bradner & Mankin [Page 9]