One document matched: draft-hancock-nsis-fw-outline-00.txt
Internet Draft Robert Hancock
Eleanor Hepworth
Document: draft-hancock-nsis-fw-outline-00.txt Siemens/Roke
Manor Research
Expires: November 2002 May 2002
An Outline Framework for QoS Signalling Protocols
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
The Next-Steps-in-Signalling (NSIS) working group of the IETF is
considering the requirements for QoS signalling protocols [2]. One
element of this, and follow up work, is to develop a framework within
which existing and proposed protocols can be analysed, and which
captures how QoS signalling protocols should interact, both with each
other and with other components of the Internet, such as routing
protocols or AAA mechanisms. Because of this aspect of interactions,
the scope of an NSIS framework is necessarily broader than the scope
of any new NSIS protocol.
Previous work suggests that a complete QoS signalling framework is a
major undertaking. This Internet Draft outlines the principal
components of such a framework and their interrelationships. It could
be used as a starting point for more detailed investigation of
individual components. It could also be used to refine the scope of
NSIS more precisely, both in terms of what functions are to be
considered and how many variant approaches are relevant.
Outline Framework for QoS Signalling May 2002
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
Table of Contents
1. Introduction...................................................3
1.1 Purpose....................................................3
1.2 Scope......................................................3
1.3 Structure..................................................4
2. Overall Framework Structure....................................4
2.1 Signalling Entities........................................4
2.2 Protocol Locality..........................................5
2.3 Protocol Function Split....................................5
3. Basic Protocol Components......................................6
3.1 QoS (Service) Descriptors..................................6
3.2 Flow Description...........................................7
3.3 NSIS Control Information...................................7
3.4 Protocol Transport.........................................7
4. Non Local Aspects..............................................8
4.1 Application Layer Interactions.............................8
4.2 End-to-End Paths...........................................8
4.3 Extensions.................................................9
5. Inter-Layer and Inter-Protocol Interactions....................9
5.1 Resource Management........................................9
5.2 AAA Interactions..........................................10
5.3 Routing...................................................11
5.3.1 Signalling and Data Paths ..............................11
5.3.2 Route Change and Mobility (Handover) Support ...........11
5.3.3 Access Router Selection and Handover ...................12
6. Additional Analysis Areas.....................................12
6.1 State Information Storage.................................12
6.2 Scalability...............................................13
6.3 Resilience................................................13
6.4 Interworking..............................................13
6.5 Security Considerations...................................13
References.......................................................14
Acknowledgments..................................................14
Author's Addresses...............................................14
Hancock et al. Expires - November 2002 [Page 2]
Outline Framework for QoS Signalling May 2002
1. Introduction
This document provides an outline framework for the discussion,
analysis and design of QoS signalling protocols for the Internet.
Previous work [4] indicates that a framework document that covers all
the issues of QoS signalling in all network scenarios can rapidly
become large and hard to manage. On the other hand, if parts of the
QoS problem are considered only in isolation there is a danger that
interactions and implications are missed. This i-d provides an
overview of what an NSIS framework could (or should) consider. Any of
the sections (or subsections) of this document could be dramatically
expanded.
1.1 Purpose
We think an overall NSIS framework would have a 5-fold purpose:
1. Enable refinement of requirements where this has to be done by
consideration of some concrete proposal (e.g. a security threat
analysis is easier in the context of some sort of framework).
2. Enable refinement of the scope of the NSIS itself.
3. Enable analysis of existing solutions ("does protocol X fit to
the function which is required to do Y?").
4. Enable more detailed analysis of particular parts of the problem
in (relative) isolation, while capturing interactions with other
protocols (and indeed working groups).
5. Capture some basic assumptions about how NSIS protocol(s) should
be structured.
Obviously these goals are not all comparable, and relate to different
stages of the overall process. The tension between modelling existing
protocols and designing new ones may pull the framework activity in
different directions.
1.2 Scope
Some things are assumed excluded from the NSIS framework activity.
Firstly, we are not considering an overall QoS framework: we only
consider that NSIS interacts with other functions at the protocol
endpoints, we don't consider in detail how these other functions
should be implemented in the network (unless this has some impact
back on the QoS signalling itself). Also, support for multicast is
not considered, nor are specifics of particular network scenarios.
However, because the NSIS problem includes these interactions and
also interworking with existing QoS signalling protocols, the scope
of consideration is necessarily broader than given by the NSIS
Hancock et al. Expires - November 2002 [Page 3]
Outline Framework for QoS Signalling May 2002
requirements themselves. This i-d does not modify those requirements;
it should eventually be validated against them.
Ideally the framework should define common terminology (eventually).
1.3 Structure
Section 2 proposes a set of basic assumptions for the framework,
including the assumption that most interactions are hop-by-hop.
Section 3 considers a decomposition of the components that would make
up an NSIS protocol exchange.
Section 4 considers aspects of the framework that relate to a longer
range than pure hop-by-hop interactions.
Section 5 considers lower layer and inter-protocol interactions.
Section 6 considers overall analysis themes, such as security,
resilience, and scalability, which do not relate specifically to a
single part of the framework.
2. Overall Framework Structure
2.1 Signalling Entities
We assume that an NSIS signalling protocol runs between two
neighbouring entities which are a single 'NSIS hop' apart. In [4]
these were called 'NSIS agents'. An NSIS agent is responsible for
interpreting the resource requests in NSIS messages and applying them
('QoS provisioning') over its segment of the flow path; the complete
flow path is made up of a concatenation of NSIS hops.
We make no assumptions about the relationship between NSIS agents and
the flow path, except that the former must know enough about the
latter to carry out the provisioning action. In particular, NSIS
agents do not need to be at each router, or even located at routers
at all. They can be placed around networks in various different
configurations, covering the spectrum from centralised management all
the way to pure hop-by-hop RSVP. But we don't want to relate this
overview to any particular example configurations.
In [4] and subsequent discussions we considered 3 subtypes of NSIS
agent: the QoS Initiator (QI), which starts the reservation process
based on upper layer requests (e.g. an application); the QoS
Controller (QC), which processes and forwards the reservation; and
the QoS Responder (QR), which terminates it at the remote flow
endpoint. Note that there may be QI-QC-QR chains in the core of the
network as well as end to end (e.g. in the case of network management
dynamically provisioning an aggregate). The basic situation is shown
in Figure 1.
Hancock et al. Expires - November 2002 [Page 4]
Outline Framework for QoS Signalling May 2002
+----+ +----+
| UL | | UL |
+----+ +----+
^ ^
| |
| |
V V
+----+ +----+ +----+ +----+ +----+
| | NSIS | | NSIS | | NSIS | | NSIS | |
| QI |------->| QC |------->| QC |------->| QC |------->| QR |
| | | | | | | | | |
+----+ +----+ +----+ +----+ +----+
/----------------------------------------------------\
/ \
< Flow (unidirectional) >
\ /
\----------------------------------------------------/
Figure 1: QI, QC and QR
There is a minor ambiguity as to whether we consider a QC as really
terminating one NSIS protocol instance and initiating another (i.e.
QC=QI+QR). This seems to be purely an issue of semantics.
2.2 Protocol Locality
A goal of this framework is to allow maximum freedom for local
(operator or technology influenced) selection of QoS mechanisms
within particular networks. One consequence of this is that it should
be possible to select different NSIS protocols (or use existing
protocols) at different points in the end to end path. A minimum set
of attributes needs to be common to all protocols to make
interoperability possible (see section 4). Also, we don't assume any
particular overall QoS architecture, at least in part because we
don't say anything about how QoS is actually enforced by the NSIS
agents.
2.3 Protocol Function Split
We know the basic goal of an NSIS protocol is to establish state
related to resource reservations. There seems to be a split into the
most basic messages needed to support this function, and supporting
protocols which set up associated information beforehand.
The basic capability would include: request to create/modify a
reservation; acknowledge a reservation (maybe modified); and
Hancock et al. Expires - November 2002 [Page 5]
Outline Framework for QoS Signalling May 2002
asynchronously notify a change in the reservation state. It is
assumed that an NSIS protocol would support these functions directly.
Conversely, a preparatory phase could include elements such as
discovering the next hop NSIS agent, setting up a security
association, and agreeing QoS service descriptions or defaults. It is
not clear which of these functions NSIS protocols should support (it
might provide a container or activate triggers for other protocols).
This preparatory/basic split is almost analogous to the two phase
approach (main/quick) which seems to have been found useful in IKE.
Also, appropriate protocols for parts of the preparatory exchanges
may be highly scenario dependent (cf. the current discussion on
mechanisms for DNS server discovery) but not NSIS-specific.
3. Basic Protocol Components
Although we could consider an NSIS 'basic' protocol as a single
layer, it makes sense to subdivide the message content into
components, as in Figure 2.
+-------------------------------------------------------------------+
| | | | / / / / / / / |
| | | |/ / / / / / / /|
| | | | / / / / / / / |
| Protocol | NSIS | Flow |/ / / QoS / / /|
| Transport | Control | Description | / Descriptor/ |
| | Information | |/ / / / / / / /|
| | | | / / / / / / / |
| | | |/ / / / / / / /|
+-------------------------------------------------------------------+
Figure 2: Abstract Message Structure
The division into these components seems arbitrary, and could lead to
inefficiences in terms of duplication of functions. However, it
reflects requirements-related decisions about NSIS scope and can help
describe how NSIS protocols can be terminated or interworked at
different boundary types. It therefore needs to be analysed according
to some engineering principles.
3.1 QoS (Service) Descriptors
It is a working assumption that the NSIS signalling protocol does not
care how QoS for a flow is actually described. In particular, we
don't argue about service classes, or parametrised approaches, or
opaque references to pre-negotiated service level specifications. The
expectation is that these descriptors will be very different at
Hancock et al. Expires - November 2002 [Page 6]
Outline Framework for QoS Signalling May 2002
different network interface types. Also, the service description can
encompass many of the more sophisticated QoS features (pre-emption,
resource availability notification, time-limited sessions) without
polluting the structure of the basic protocol. This information is
therefore carried opaquely by the protocol, and only used during QoS
provisioning.
However, QoS service descriptions need to be analysed at least to
some extent to determine their impact on the protocol (e.g. how many
message exchanges are needed to negotiate them, whether a particular
service requires additional per-flow state storage). Also, at least
the top-level syntax (IANA aspects etc.) need to be defined.
The abandonment of universal QoS descriptions has interoperability
implications especially for host-network interfaces especially in
terminal roaming environments. It probably makes less likely the wide
adoption of rich descriptive parameters (e.g. as proposed in [5]).
One way round this would be to consider associating scope information
with the QoS description, as described in [4].
3.2 Flow Description
The flow description defines the traffic that is the subject of the
reservation. This description could potentially be very simple, or
use very sophisticated multi-field classification (even including
field re-writing rules). It is also technology dependent (v4, v6...)
One reason for separating the flow description from the rest of the
information is to allow it to be managed correctly by devices which
are otherwise QoS-unaware (e.g. address translators, tunnel
entry/exit points). The way such transformations affect protocol
overhead (and hence flow QoS requirements) needs to be accounted for.
3.3 NSIS Control Information
This represents the remaining NSIS-specific information carried by
the signalling protocol. It includes information about message type,
status information, reservation identification and so on. Although
conceptually different from the transport of section 3.4 the two
could in fact end up being inextricably intermingled.
3.4 Protocol Transport
NSIS basic signalling protocols have many attributes in common with
standard signalling protocols, such as the need for secure and timely
delivery, recovery from error conditions, prevention against denial
of service attacks, and so on. Ability to be proxied or relayed in a
controlled way could also be important. None of these attributes is
Hancock et al. Expires - November 2002 [Page 7]
Outline Framework for QoS Signalling May 2002
specific to QoS signalling, and so it is likely that existing
protocols (such as SCTP or even Diameter) could be used to transport
NSIS messages. The choice of protocol might still be local (cf. the
way PPP and Diameter are used eat different stages to carry
Extensible Authentication Protocol [EAP] message exchanges). Suitable
protocols need to be selected.
4. Non Local Aspects
It is clear that the NSIS signalling problem is simpler if as many
problems as possible are considered purely locally (i.e. hop by hop).
For some functions this is not possible, and for others it imposes
certain restrictions, which are considered here.
4.1 Application Layer Interactions
Considering unicast (1:1) application flows (or triggered
aggregates), the NSIS entities responsible for the signalling are the
QI and QR of section 2.1. We note that the QI and QR might not be
colocated with the application or the user; however, this decoupling
should not be relevant to the protocol (except that the signalling
and traffic endpoints need not be the same). In particular, we would
like to consider that the security implications of a remote QI/QR are
handled elsewhere.
In that case, as in [4], we assume that the main interaction with the
application is that it requests negotiation of the QoS at the QI
(where it might also receive notifications), and is notified about it
at the QR. We assume that the decision about which application end
plays which role (for which flow direction) is made above NSIS (a
direct end-to-end NSIS protocol could do this but the application
seems better placed).
4.2 End-to-End Paths
Even where NSIS basic protocols are selected locally, some aspects
must be common to allow end-to-end interoperation. Constraints
related to the basic signalling paths for sender/receiver-initiated
and bidirectional reservations are considered extensively in [4]. Two
further related open issues are mentioned here.
It is not clear if 'initiation' of a reservation is related to
willingness to accept accounting responsibility. (Current accounting
practices tend to assume that flow originators are responsible.) In
any case, it seems unlikely that a domain will make a cost-incurring
request of a peer domain without already having received a matching
request from the peer at the other end of the flow path - in other
words, requests must propagate between domains in the same direction
Hancock et al. Expires - November 2002 [Page 8]
Outline Framework for QoS Signalling May 2002
as money. If this argument is correct, and if NSIS initiation and
accounting responsibility are decoupled, it must be possible for the
NSIS exchange to run both in the direction initiator->responder and
vice versa. Also, if both [flow] sender and receiver initiation are
possible, service descriptions must include information about the
accounting policy to be applied, which must be imposed consistently
along the whole path. These issues should be analysed to determine if
1, 2 or 4 alternative scenarios are possible.
A second issue relates to the semantics of acknowledgement messages
in the basic protocol. An acknowledgement could mean either "I have
accepted this request for my domain [or hop]" or "this request has
been accepted for the remainder of the path". The first approach is
simpler (except in error cases), while the second requires more state
storage but could enable reporting of overall path characteristics.
(It replicates aspects of end-to-end RSVP behaviour.) The choice
between the two must be made consistently by all NSIS basic
protocols.
4.3 Extensions
Various extensions to the pure hop-by-hop model could be considered
to build more sophisticated operational scenarios. Otherwise, with
the basic protocol features being considered, it is not clear that
NSIS could be used to build more complex services such as collect
calls, advice of charge, sensible charging of calls to a roaming
mobile, where the path crosses more than one administrative domain.
It is not clear whether these service capabilities are necessary
within the Internet, and if so whether their implications need to be
considered in the first stages of NSIS development.
5. Inter-Layer and Inter-Protocol Interactions
This section considers the interactions between an NSIS basic
protocol and other protocols. While inter-layer interactions are
usually easy to model ("protocol X uses the service provided by
protocol Y"), intra-layer interactions (especially those relevant to
QoS signalling) are more subtle since they involve internal protocol
components such as state transitions or security parameters. This
area may require the development of abstract APIs to these other
protocols, although the interactions would in the end still be
implementation issues.
5.1 Resource Management
The term "resource management" covers the various actions which are
taken to apply the QoS requested in the NSIS signalling message (QoS
Hancock et al. Expires - November 2002 [Page 9]
Outline Framework for QoS Signalling May 2002
descriptor) to the flow defined in the signalling message. It also
includes preparatory interactions to decide whether the request is
feasible and maybe negotiate its content.
This NSIS framework assumes the following come under the remit of
resource management:
1. Determination based on some local or network view whether the
request can be granted.
2. Configuration of layer 3 resources (filters and queues) at
routers along the path.
3. Configuration of layer 2 resources (link characteristics) at
routers and other devices along the path.
The framework makes no assumptions about how these are done, merely
that they can be done based on the information contained in the NSIS
messages. All QoS provisioning architectures with these capabilities
will 'look' the same to the signalling protocol.
As well as invoking QoS provisioning, the NSIS protocol must also
interact with resource management for notification of changes to the
available resources for a flow violation notifications can be sent.
The same applies to availability notifications and pre-emption, if
these services are supported.
5.2 AAA Interactions
NSIS implementations within the network will have interactions with
authentication, authorisation and accounting functions. Although
protocol support for these is often integrated, it seems we can make
very different assumptions about the interactions with QoS signalling
for each.
The authentication interaction relates to peer entity authentication
(e.g. user/host-network) rather than authentication backhaul (e.g.
using RADIUS). This authentication is needed to establish the
identity of the user for later authorisation of QoS requests. The
authentication can also be used to set up security parameters for
later use.
Note here that we are assuming that the authentication function is
provided by an external protocol rather than by an NSIS function
(e.g. within the preliminary phase). The interaction might be
mediated through some abstract API, such as the EAP API that crops up
in roaming PPP discussions [6]. Other authentication protocols could
be integrated similarly.
Subsequent to authentication, authorisation information can be
provided to the QC. However, it appears that this information is used
only by the resource management function in admission control
Hancock et al. Expires - November 2002 [Page 10]
Outline Framework for QoS Signalling May 2002
decisions and has no direct interaction with NSIS signalling, except
via the message sequence constraints discussed in section 4.2. The
same reasoning applies to accounting information flows.
5.3 Routing
This section considers interactions with routing and routing
protocols. Except to note that routes might be QoS dependent, we
don't consider QoS-aware routing or traffic engineering, since
controlling this would be a function of resource management, with no
implication back on the QoS signalling protocol.
5.3.1 Signalling and Data Paths
The relationships between the routing of user data and the signalling
messages that request QoS for it have been extensively discussed in
[4] and elsewhere. Here, we just note that implicit routing of
signalling messages on flow destination address does not guarantee
that signalling follows the data path (because of QoS routing), and
explicit addressing of QoS messages might be used in any case for
security or other reasons (as is necessary for RSVP messages in some
cases).
It seems that the only impact on the signalling protocol is to allow
explicit addressing of messages. Discovering the explicit address is
therefore required, but we have regarded this discovery as an aspect
of the preliminary phase rather than part of the basic protocol.
5.3.2 Route Change and Mobility (Handover) Support
When the path taken by a traffic flow changes, the reservation must
be changed to match it. Such a change could take place either because
of a topology change or end host mobility. There are two areas where
interaction with NSIS signalling might take place: in detecting the
route change, and sending update signalling messages.
Route changes can be detected by a trigger from the routing protocol
(which is natural if signalling messages are explicitly routed). If
signalling is implicitly routed and the NSIS agents are routing
unaware, it appears that there is no alternative to soft-state
refresh, in which case the updating process is automatic. Beyond
this, there seem no additional mandatory implications for routing-
NSIS interactions.
Substantial research work has been done in considering the detailed
interactions of QoS signalling and mobility routing protocols. This
has considered both independent protocols interacting via triggers as
in the previous paragraph, as well as a tighter coupling mode where
Hancock et al. Expires - November 2002 [Page 11]
Outline Framework for QoS Signalling May 2002
the QoS messages are carried within routing protocol messages. This
case can be considered as a local NSIS protocol, with the mobility
routing protocol playing the role of NSIS transport in the sense of
section 3.4. The relative merits of these approaches can be analysed,
but both fit naturally into the framework outlined here.
5.3.3 Access Router Selection and Handover
Also in the mobility area, work is going on to consider protocols for
selecting access router handover targets. One selection criterion
would be QoS available at the candidate access router, over both the
access link and into the rest of the network. There is a clear
interaction with NSIS signalling here, partly because NSIS may also
support a query capability, and also that NSIS agent implementations
will have the necessary interfaces to resource management to do parts
of this. It seems very unclear how to manage this protocol
interaction, although the ability to reuse components of NSIS
messages for the QoS-related aspects of the signalling could be
useful.
6. Additional Analysis Areas
The following sections consider areas which cut across all aspects of
the framework. They therefore need to be analysed for each aspect, as
well as looking at the way these aspects work together to support the
function overall.
6.1 State Information Storage
The NSIS framework may be assessed in terms of what state information
is required at which points in the network and for which
interactions. Some state information must be maintained at NSIS
agents, minimally in order to support protocol operation, such as:
1. Flow Information: to allow identification of a flow/aggregates
for re-negotiation and allow notifications to be propagated to
right node. The resource allocated is also part of this state.
2. Aggregation information: to allow disaggregation and the
regeneration of reservation information.
3. NSIS Agent associations: including authentication state and
accounting policy associated with NSIS peers.
Since NSIS also carries QoS descriptions, there may be additional
information associated with these (to do with more complex services
such as time limited reservations) which is otherwise unknown to
NSIS. Likewise, resource management will need state information about
what resources are in use by whom. Whether to integrate this with
protocol state handling might be left as an implementation issue.
Hancock et al. Expires - November 2002 [Page 12]
Outline Framework for QoS Signalling May 2002
6.2 Scalability
Scalability analysis of the different aspects of the framework can
provide indications regarding protocol performance and efficiency.
The analysis can be carried out independently for different framework
aspects, for example, the impacts of a particular security approach
in terms of signaling vs. state information.
6.3 Resilience
Analysis of resilience requires identification of what failure
conditions need to be handled by NSIS, followed by an assessment of
how recovery takes place for different aspects of the framework. The
impacts of the failure of one part of the framework on another also
need to be considered, for example, should state information
availability be dependent on ("fate share with") node or signaling
path failure, or should at least some parts of the state information
(e.g. authentication state) be decoupled.
6.4 Interworking
Solutions developed within NSIS should support interworking with
existing QoS solutions, such as RSVP, or MPLS. This supports
incremental deployment of NSIS solutions in existing QoS-enabled
networks. This requirement seems to impact on all aspects of NSIS.
6.5 Security Considerations
This internet draft has security considerations in almost every
aspect. However, no explicit security requirements or proposals are
made in it (except that some options are given about potential
interactions with existing security protocols). Instead, this
internet draft is aimed at progressing security analysis.
Security requirements are given in [2], and a more detailed threat
analysis is on-going. This analysis can initially only be done at the
user/system level; however, it is possible to do a more specific
threat analysis against a more concrete protocol framework.
A particular issue for the security considerations is the fact that
NSIS is a container protocol for QoS descriptions which are otherwise
not considered. Some security requirements (e.g. theft of service)
apply mainly to these QoS descriptors and associated authorisation
aspects, while others (e.g. denial of service/flooding) apply more to
the NSIS parts. We then have three possible basic approaches:
1. Assume that the authenticated and secure QoS descriptors will
always be required, and build on this to secure other aspects of
the protocol, such as denial of service attack prevention.
Hancock et al. Expires - November 2002 [Page 13]
Outline Framework for QoS Signalling May 2002
2. Have the NSIS parts include a security service which can be used
also to secure the QoS description.
3. Consider the two parts independently.
One open question is whether the assumption (1) is valid, or whether
secure anonymous access should also be considered (e.g. as provided
by HIP [7]).
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Brunner, M., "Requirements for QoS Signaling Protocols", draft-
ietf-nsis-req-02.txt (work in progress), May 2002
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
4 Hancock, R.E. et al., "Towards ...", draft-hancock-nsis-framework-
00.txt (work in progress), February 2002
5 Fodor, G., "Application of Integrated Services on Wireless
Accesses", draft-fodor-intserv-wireless-params-01.txt (work in
progress), January 2002
6 Aboba, B., "The EAP Keying Problem", draft-aboba-pppext-key-
problem-01.txt (work in progress), February 2002
7 Moskowitz, R., "Host Identity Payload And Protocol", draft-
moskowitz-hip-05.txt (work in progress), November 2001
Acknowledgments
The authors would like to acknowledge Cornelia Kappler and Hannes
Tschofenig for input and comments, as well as all the other co-
workers, colleagues from collaborative projects, and active players
in the NSIS working group who have broadened our horizons on the
subject of QoS signalling architectures over the past months.
Author's Addresses
Robert Hancock
Eleanor Hepworth
Siemens/Roke Manor Research
Old Salisbury Lane, Romsey, U.K.
Email: {robert.hancock|eleanor.hepworth}@roke.co.uk
Hancock et al. Expires - November 2002 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 09:58:25 |