[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG Review: Next Steps in Signaling (nsis)
A new IETF working group has been proposed in the Transport Area.
The IESG has not made any determination as yet.
The following Description was submitted, and is provided for
informational purposes only:
Next Steps in Signaling (nsis)
Current Status: Proposed Working Group
Description of Working Group:
Quite a bit of work has been done on Quality of Service and resource
reservation for the Internet. For a number of reasons, however, there
has not been a significant amount of end-to-end QoS deployed on the
Internet other than best effort service.
It is noted that resource reservation and traffic engineering can be
considered as part of network administration, and therefore beyond the
scope of the IETF to mandate a particular mechanism. When considering
end-to-end communication, it is likely that several administrative
domains are traversed. Interworking between domains in which different
QoS solutions solutions are deployed is problematic. Mobility and
roaming additionally add complexity to the overall picture. This
creates a need for a simplified solution of signaling QoS, one that
reuses parts of existing methods. This will allow users to obtain
QoS-aware services, irrespective of underlying mechanisms used.
This working group will develop the requirements, architecture and
protocols for the next IETF steps on signaling QoS. The working group
will use existing IETF signaling as the basis for this work, evaluating
RSVP in particular as the starting point. Additionally, the working
group will consider how to signal QoS (what sort of QoS parameters
to use), and where to signal (end-to-end, end-to-edge, end-to-proxy,
Requirements document (draft-mobileip-qos-requirements) will be
considered as one starting point for developing the overall set of
requirements. The working group will not limit itself to mobile
IP-only QoS signaling needs, however, but will consider general cases
of signaling QoS in the Internet (both wired and wireless).
Consideration will be given to the idea of a building block structure,
so the group could develop elements for QoS signaling that could be
modular and be combined with a different payload or different proxy
(e.g.) for use by a non-QoS signaling function. The added function will
be out of scope, but the openness of the design (which may be a new
version of RSVP) will be in scope.
This working group will focus on providing (QoS) signaling function to
a local access network and end-to-end signaling. It is not the
intention of this working group to invent new signaling protocols.
Additionally, mobility protocols and AAA work are out of scope of the
working group. The work produced in this Working Group should work
with existing IETF mobility and AAA protocols, including (but not
limited to) Mobile IP, SeaMoby Context Transfer and Diameter.
The working group will develop signaling requirements, analysis and
framework documents. The Transport area directors and chair will
evaluate these against criteria including that the use of a simplified
version of RSVP has been fully evaluated, and that the potential for a
tool box or building block contribution has been covered by the
framework. Work on the protocol document will be contingent on this
As with nearly all work being done in the IETF, security is a very
important concern for NSIS. The working group will study the security
requirements for QoS Signaling, as well as create a threat analysis of
QoS signaling. Compatibility with authentication and authorization
mechanisms is also a concern. These topics will be addressed in the
Signaling Requirements document.
This working group will provide the framework for interworking with
existing resource allocation methods. It is a non-goal of the working
group to develop new resource allocation protocols.
The working group will coordinate with a number of other IETF working
groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP. It
will also welcome participation and expression of requirements from
non-IETF standards organization members, for instance 3GPP and 3GPP2 and