[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                  NSIS Working Group                                    Maarten Buchli
                  Internet Draft                                         Danny Goderis
                  draft-buchli-nsis-req-00.txt                      Sven Van den Bosch
                  Expires: August 2002                               Juan-Carlos Rojas
                                                                        Stefan Custers
                                                                               Alcatel
                                                                          February 2002
               
               
                         QoS signaling requirements, interfaces and architecture
               
               
               Status of this Memo
               
                  This document is an Internet-Draft and is in full conformance
                  with all provisions of Section 10 of RFC2026.
               
               
                  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
               
                  This draft gives evidence for the existence of different QoS
                  signaling interfaces based on a reference architecture that is
                  derived from two use cases. The main purpose is to refine the
                  requirements for the signaling interface that is being considered in
                  scope of NSIS.
               
                  The two use cases are the interconnection of PSTN trunking gateways
                  over an IP core network and the connection of an UMTS access network
                  to an IP core network. From these use cases a QoS reference
                  architecture is derived containing QoS Initiator (QI) and QoS
                  Controller (QC) entities, as defined in draft-brunner-nsis-req-
                  00.txt. The architecture encompasses the inter-connection of any
                  type of access networks over an IP DiffServ core network and does
                  not require any upgrade of the existing (and deployed) DiffServ
                  routers.
               
                  The proposed architecture identifies four relevant signaling
                  interfaces between functional entities. We believe the interface
                  between QI and QC to be of particular interest in the context of
               
                  Buchli et al. Informational - Expires August 2002                1
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  NSIS. Based on our architecture, the signaling protocol over this
                  interface can be kept simple.
               
               
               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 [1].
               
               
               Table of Contents
               
                  Status of this Memo................................................1
                  Abstract...........................................................1
                  Conventions used in this document..................................2
                  1. Introduction....................................................3
                  2. Terminology.....................................................4
                  3. Overview of signaling requirements..............................5
                  4. Use cases.......................................................6
                  4.1 PSTN trunking gateway scenario.................................7
                  4.2 UMTS access scenario...........................................8
                  5. General architecture............................................9
                  5.1 Signaling architecture........................................10
                  5.2 Protocol interfaces...........................................13
                  5.2.1 Host to QoS Initiator.......................................13
                  5.2.2 QoS Initiator to Access Gate................................13
                  5.2.3 QoS Initiator to QoS Controller (NSIS)......................14
                  5.2.4 QoS Controller to Network Management System (NMS)...........14
                  5.3 Evolution scenario............................................15
                  6. Requirements on the QoS Initiatorûto-QoS Controller interface..15
                  6.1 Signaling requirements........................................15
                  6.2 Requirements on protocol content..............................17
                  6.3 Open issues...................................................18
                  7. Security Considerations........................................18
                  8. Conclusions....................................................19
                  9. Acknowledgment.................................................20
                  References........................................................20
                  Author's Addresses................................................21
               
                  Buchli et al. Informational - Expires August 2002                2
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
               1. Introduction
               
                  The task of the NSIS working group is to specify general QoS
                  signaling requirements and possibly propose a new protocol or
                  modifications to existing ones.
               
                  Two use cases are presented in this draft to explore such QoS
                  signaling requirements. The first case is a PSTN trunking gateway
                  interconnection scenario. The second case is the interconnection
                  between a UMTS access network and an IP core network.
               
                  In addition to the NSIS requirements draft [8], and based on the two
                  use cases, we introduce a QoS signaling reference architecture and
                  identify the different protocol interfaces that are in place. An
                  important observation is that several QoS signaling interfaces may
                  exist and that their requirements are of a different nature. We
                  identify four relevant signaling interfaces, which may be involved
                  in QoS provisioning. The most important being the interface between
                  the QoS Initiator (QI) and the QoS Controller (QC) as also described
                  in [8].
               
                  The basic requirements of the QI-to-QC interface are described and
                  compared with the requirements as expressed in [8]. In particular it
                  must be possible to gradually deploy the NSIS QoS solution on top of
                  existing networks. This high-level requirement yields concrete
                  consequences for the QoS signaling in as well access as core
                  networks.
               
                  First it is noted that access networks (UMTS, Packet cable, ADSL
                  access, etc) may use their own specific QoS signaling protocols for
                  quite some time. Moreover, in current networks, QoS signaling in
                  access may be very technology dependent, while for IP core networks
                  we need definitely a technology independent protocol. This may
                  involve mapping requirements and the draft discusses particular
                  features of this mapping and the actual place in the network where
                  this mapping can take place.
               
                  Thus, in a first phase, access networks may still use their own QoS
                  signaling, which is mapped onto a generic NSIS protocol by an entity
                  at the edge of the network. However, in a second phase the NSIS
                  protocol may also be supported by the end-host and used in the
                  access networks to setup QoS reservations. Hence, this provides an
                  evolution scenario for gradual deployment of the NSIS protocol in
                  access networks.
               
                  Second the QoS technology used by most operators in IP core networks
                  is Differentiated Services (DiffServ). It should be possible to
                  deploy the QoS solution onto these networks without upgrading the
                  routers. This may require the compatibility of in-band and out-of-
                  band signaling because, for pure DiffServ networks, the QoS
                  signaling can not be done on the data-path. This draft presents one
                  way of doing this for scenarios involving one IP core and several
                  access networks. It presents a two-step approach in order to support
               
                  Buchli et al. Informational - Expires August 2002                3
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  end-user Quality of Service (QoS). First step is to pre-provision
                  bandwidth pipes in the transport network defined by means of e.g.
                  DiffServ Service Level Specifications (SLS). These are e.g. IP VLLs
                  with statistical QoS guarantees, such as edge-to-edge delay and
                  packet loss bounds, for traffic aggregates. The second step is then
                  to admit (micro)-flows in the bandwidth pipes based on the user QoS
                  request. As a consequence of this two-step approach, the dynamic
                  per-flow QoS signaling can be simplified and kept out of the
                  (DiffServ) routers.
               
                  The outline of the draft is as follows.
                  The terminology is defined in section 2. Section 3 summarizes the
                  main signaling requirements for the QI-to-QC interface and makes the
                  comparison with [8]. Section 4 presents the two use cases while
                  section 5 draws conclusions and proposes a more general signaling
                  architecture. The requirements on the signaling protocol and the
                  parameter groups are discussed in section 6. The conclusions are
                  presented in the final section.
               
               
               2. Terminology
               
                  The terminology used in this draft is in line with the DiffServ
                  terminology [10] and the NSIS requirements draft from Brunner et al.
                  [8]. The relevant terminology is repeated here and some new terms
                  are introduced. See e.g. figure 3 for a position of the relevant
                  functional entities in the network.
               
                  Host: end-user entity where the application is running that requires
                  QoS to another host or server. The end-user service, which should be
                  supported end-to-end by the network, is supposed to be a dynamic QoS
                  demanding service such as voice, video, etc.
               
                  Access Gate (AG): functional entity that enforces QoS policy by
                  policing and traffic conditioning per microflow.
                  In this context, a microflow is understood as the IP packet flow
                  carrying the payload of the actual service to be supported in the
                  network (e.g. voice) and may be formally defined as e.g. the IntServ
                  5-tuple. A microflow is always understood to be end-to-end, i.e.
                  host-to-host.
               
                  Edge router (ER): router at the edge of a Differentiated Services
                  (DiffServ) capable network. It is a common DiffServ edge router
                  enforcing QoS policy by policing and traffic conditioning traffic
                  aggregates and DiffServ Service Level Specifications SLS, see e.g.
                  [8][9].
                  According to DiffServ an SLS is "a set of technical parameters and
                  their values, which together define the service, offered to a
                  traffic stream by a (DiffServ) transport network". In this context,
                  an SLS is the technical specification of a long-lived QoS service
                  such as an IP VLL or an assured rate bandwidth pipe. The
                  geographical scope of an SLS is single domain, i.e. edge-to-edge.
                  The edge-to-edge statistical QoS guarantees, such as maximum delay,
               
                  Buchli et al. Informational - Expires August 2002                4
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  are provided to the in-profile packets of the traffic aggregate
                  stream defined by the SLS. For a detailed description of SLSs, see
                  [9]. For its support and implementation in a DiffServ network by
                  means of Per Hop Behaviors (PHB) and Per Domain Behaviors (PDB), see
                  [8].
               
                  Network Management System (NMS): common network and element
                  management platform, configuring the edge and core routers of a
                  single IP network by e.g. the SNMP or COPS protocol. In this context
                  the NMS is the functional entity responsible for the configuration
                  and provisioning of long-lived QoS services, which are technically
                  described by SLSs.
               
                  QoS Controller (QC): the functional entity that is ôresponsible for
                  interpreting the signaling carrying the end-user service QoS
                  parameters, optionally inserting/modifying the parameters according
                  to local network QoS management policy, and invoking local QoS
                  provisioning mechanismsö [8]. More specifically in this context the
                  QC performs per-microflow admission control for a single IP domain.
                  The QC manages or "owns" (part of) the pre-provisioned network
                  resources, which are described by a set of Service Level
                  Specifications. These SLSs provide statistical edge-to-edge QoS
                  guarantees.
               
                  QoS Initiator (QI): the functional entity ôgenerating the QoS
                  request for traffic flow(s) based on user or application
                  requirements and signaling them to the network as well as invoking
                  local QoS provisioning mechanisms.  This can be located in the end
                  system, but may reside elsewhere in networkö [8]. This draft takes
                  the same viewpoint and discusses use cases for different locations
                  of the QI. The QI is in any case an ôNSIS-speakerö, i.e. it
                  implements the (to-be-defined) NSIS protocol and signals a QoS
                  request to the QC. In case the QI is situated at the network edge
                  (access-core), the QI should perform a mapping from the (access
                  technology dependent) user QoS request to the QoS request towards
                  the QC.
               
               
               3. Overview of signaling requirements
               
                  The main purpose of this document is to derive requirements for NSIS
                  protocol interfaces that are identified from use cases. In this
                  section, we give an overview of the requirement list. The
                  requirements are primarily derived for the QI-QC interface but it
                  seems advantageous that they be reused (partly) for the QC-QC
                  interface. Each requirement will be put into context and clarified
                  in subsequent sections.
                  Apart from the generic requirements that the protocol should be fast
                  and lightweight, it
               
                  - must support both in-band and out-of-band signaling
                  - must support priority
                  - must allow notification of (QoS) failure
               
                  Buchli et al. Informational - Expires August 2002                5
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  - must decouple the messaging mechanism from the information being
                     signaled
                  - should be independent of core transport technology
                  - should avoid extra complexity due to (optional) multicast support
                  - should be optimized for interactive multimedia services
                  - should support different service levels for a service class
                  - the mobility aspects should have no impact on the NSIS protocol
               
                  Two considerations are left as open issues:
                  - the protocol may be stateful or stateless
                  - it should consider allowing grouping of microflows
               
                  Related work in the NSIS group [8] states that:
                  "Specific mechanisms for QoS provisioning within a domain/subdomain
                  are not considered. It should be possible to exploit these
                  mechanisms optimally within the end to end context. Consideration of
                  how to do this might generate new requirements for NSIS however."
               
                  The two-step approach for which requirements are documented in this
                  draft achieves this goal of exploiting the QoS intra-domain
                  provisioning solution. In this way, it inherently addresses some of
                  the requirements in [8]:
                  - it avoids duplication of sub-domain signaling
                  - it provides independence of the underlying technology
                  - it reuses existing QoS technologies and does not impact existing
                  infrastructure during deployment
                  - it decomposes the path which is essential to provide mobility
               
                  It also emphasizes some other requirements in [8]:
                  - QoS signaling and QoS Controllers must not be constrained to be in
                  the data path
                  - the network is expected to handle 2 QoS granularities: per-flow
                  and per-trunk or per-class
               
                  Note, however, that an important difference is that per-flow
                  signaling can be considered in the core because the required amount
                  of signaling information is strongly reduced by the two-step
                  approach.
               
                  Finally, it allows to relax some of the signaling requirements in
                  [8]:
                  - the info that is passed as signaling content does not have to be
                  universal. It suffices that it can be translated by each domain in
                  the appropriate local QoS.
                  - communication between QoS administration functionality (e.g.
                  traffic engineering) and QI is not needed.
                  - it is not necessary to map opaque application-dependent
                  information in the message. The QI provides a mapping function and
                  the end-host to end-host alignment can be obtained at the
                  application layer.
               
               4. Use cases
               
               
                  Buchli et al. Informational - Expires August 2002                6
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  In [8] the concepts of QoS Initiator (QI) and QoS Controller (QC)
                  were introduced. Here we analyze these functions for two concrete
                  use cases. In 3.1 a scenario of interconnecting PSTN trunking
                  gateways is discussed. In this case the QI and QC are integrated in
                  one entity. In 3.2 a possible scenario is shown for providing end-
                  to-end QoS with UMTS access networks. In this case the QI and QC are
                  two separate entities. In both cases the QI function is not part of
                  the end-host.
               
               
               4.1 PSTN trunking gateway scenario
               
                  This section discusses an example scenario where a number of PSTN
                  trunking gateways are interconnected by a QoS enabled IP transport
                  network. The PSTN consists of a network carrying 64 kb/s circuits.
                  It is connected to the Edge Router (ER) of the IP network by a Media
                  GateWay (MG). The PSTN call signaling is transported over a separate
                  SS7 signaling network. This signaling network is connected to a
                  Media GateWay Controller (MGC). In the IP network the SS7 signaling
                  is carried with the ISUP/SIGTRAN protocol [11]. The MGC controls the
                  MG with the Megaco protocol [5].
               
                  In figure 1 the example scenario is shown for two media gateways,
                  i.e. trunking gateways. The Network Management System (NMS) is the
                  entity that is able to provision bandwidth pipes in the transport
                  network.
               
                     +-------------+    ISUP/SIGTRAN     +-----+              +-----+
                     | SS7 network |---------------------| MGC |--------------| SS7 |
                     +-------------+             +-------+-----+---------+    +-----+
                           :                    /           :             \
                           :                   /            :              \
                           :                  /    +--------:----------+    \
                           :          MEGACO /    /         :           \    \
                           :                /    /       +-----+         \    \
                           :               /    /        | NMS |          \    \
                           :              /     |        +-----+          |     \
                           :              :     |                         |     :
                    +--------------+  +-----+   |   bandwidth pipe (SLS)  |  +-----+
                    | PSTN network |--| MG |--|ER|=====================|ER|-| MG |--
                    +--------------+  +-----+    \                       /   +-----+
                                                  \     QoS network     /
                                                   +-------------------+
               
                                 Figure 1: PSTN trunking gateway scenario
               
                  Resources should be pre-provisioned between the media gateways. This
                  is done by establishing a mesh of bandwidth pipes, with strict delay
                  guarantees, between the trunking gateways. The capacity of the pipes
                  should be determined by means of traffic prediction and use of e.g.
                  Erlang calculations in order to provision for a small call blocking
                  probability.
               
               
                  Buchli et al. Informational - Expires August 2002                7
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  The MGC receives the call setup signaling and should perform per-
                  microflow admission control onto the pre-provisioned resources.  The
                  MGC determines the rate of the microflow from the type of codec that
                  is used in the MG. The resource request is a number of 64kb channels
                  and hence, a simple counter to keep track of the used capacity of
                  the bandwidth pipe could be sufficient to perform admission control.
               
                  The MGC should have the information about the capacity of all
                  bandwidth pipes and should block call setups when the capacity is
                  completely used. The capacity of the bandwidth pipe may be
                  negotiated by an off-line process via paper contracts or by an
                  automated process with an SLS negotiation protocol.
               
                  In this scenario the MG has the role of Access Gate and the MGC acts
                  as the QoS Controller, performing admission control in the pre-
                  provisioned bandwidth pipes. The QoS Initiator functionality may
                  reside in as well the MG as in the MGC, exchanging information by
                  the MEGACO protocol. This depends on the concrete implementation of
                  MG and MGC. In any case the codec type must be mapped onto a traffic
                  descriptor, which is then used for the admission control of the
                  micro-flow into the bandwidth pipe.
               
                  In this scenario there may be a separate network provider (owning
                  the transport network and NMS) and voice service provider (owning
                  the MGs and the MGC). Both legal entities have a service level
                  agreement (SLA) and the technical part, i.e. the SLS, describes the
                  mesh of bandwidth pipes between the MGs. The existence of such a SLA
                  is shown as a line between MGC and NMS in figure 1. For more
                  details, see section 5.2 ôQC-to-NMS interfaceö. Remark also that
                  multiple service providers may be active on the same physical
                  network through SLAs with the network provider.
               
               
               4.2 UMTS access scenario
               
                  The UMTS access scenario is shown in figure 2. The Proxy-Call State
                  Control Function/Policy Control Function (P-CSCF/PCF) is the
                  outbound SIP proxy of the visited domain, i.e. the domain where the
                  mobile user wants to set-up a call. The Gateway GPRS Support Node
                  (GGSN) is the egress router of the UMTS domain and connects the UMTS
                  access network to the Edge Router (ER) of the core IP network. The
                  P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The
                  User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal
                  Equipment (TE), e.g. a laptop.
               
               
                                          +--------+
                               +----------| P-CSCF |-------> SIP signaling
                              /           +--------+
                             / SIP            :
                            :             +--------+   NSIS  +----------------+
                            :             |  PCF   |---------| QoS Controller |
                            :             +--------+         +----------------+
               
                  Buchli et al. Informational - Expires August 2002                8
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                            :                 :
                            :                 : COPS
                            :                 :
                          +----+          +--------+      +----+
                          | UE |----------|  GGSN  |------| ER |
                          +----+          +--------+      +----+
               
                                      Figure 2: UMTS access scenario
               
                  In this scenario the GGSN has the role of Access Gate. According to
                  3GPP standardization, the PCF is responsible for the policy-based
                  control of the end-user service in the UMTS access network (i.e.
                  from UE to GGSN). In the current UMTS release R.5, the PCF is part
                  of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF
                  may evolve to an open standardized interface. In any case the PCF
                  has all required QoS information for per-flow admission control in
                  the UMTS access network (which it gets from the P-CSCF and/or GGSN).
                  Thus the PCF would be the appropriate entity to host the
                  functionality of QI, initiating the "NSIS" QoS signaling towards the
                  core IP network. The PCF/P-CSCF has to do the mapping from codec
                  type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP
                  extensions to explicitly signal QoS information [7] are useful to
                  avoid the need to store codec information in the PCF and to allow
                  for more flexibility and accurate description of the QoS traffic
                  parameters. The PCF also controls the GGSN to open and close the
                  gates and to configure per-flow policers, i.e. to authorize or
                  forbid user traffic.
               
                  The QC is (of course) not part of the standard UMTS architecture.
                  However, to achieve end-to-end QoS a QC is needed such that the PCF
                  can request a QoS connection to the IP network. As in the previous
                  example, the QC could manage a set of pre-provisioned resources in
                  the IP network, i.e. bandwidth pipes, and the QC performs per-flow
                  admission control into these pipes. In this way, a connection can be
                  made between two UMTS access networks, and hence, end-to-end QoS can
                  be achieved. In this case the QI and QC are clearly two separate
                  entities.
                  This use case clearly illustrates the need for an "NSIS" QoS
                  signaling protocol between QI and QC. An important application of
                  such a protocol may be its use in the inter-connection of UMTS
                  networks over an IP backbone.
               
               
               5. General architecture
               
                  This section proposes a QoS reference architecture generalizing the
                  examples discussed above. The architecture encompasses the inter-
                  connection of any type of (layer two) access networks with an IP
                  backbone and provides QoS to any type of (uni-cast) end-user
                  services (i.e. not only telephony services). The extension of the
                  architecture to multiple IP backbones, with multiple QCs on the end-
                  to-end signaling path, is for further study.
               
               
                  Buchli et al. Informational - Expires August 2002                9
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  In 4.1 the architecture is presented. The different signaling
                  interfaces are identified and discussed in 4.2. In 4.3 an NSIS
                  evolution scenario is discussed with regard to access networks.
               
               
               5.1 Signaling architecture
               
                  The reference architecture is shown in figure 3. In this
                  architecture the host requests QoS to the QoS Initiator, which in
                  turn contacts the QoS Controller. The functional entities are shown
                  separately but they may be located in the same physical box. For the
                  sake of simplicity the access networks are presented as single lines
                  between host and Access Gates.
               
               
                              +----+   3  NSIS   +----+    NSIS     +----+
                            +-| QI |-------------| QC |-------------| QI |-+
                           /  +----+             +----+             +----+  \
                          /      :                  :                  :     \
                       1 /       :               4  : SLS IF           :      \
                        /        :            +-----:-----+            :       \
                       /         : 2         /   +-----+   \           :        \
                      /          :          /    | NMS |    \          :         \
                      :          :         /     +-----+     \         :         :
                      :          :        |                   |        :         :
                  +------+    +----+      |                   |     +----+   +------+
                  | Host |----| AG |===|ER|===================|ER|==| AG |---| Host |
                  +------+    +----+      |        SLS        |     +----+   +------+
                                           \                 /
                                            +---------------+
                                                IP network
               
                        Figure 3: QoS signaling interfaces and functional entities
               
                  The architecture identifies at least three roles, i.e. the end-user,
                  the service provider (SP) and the network provider (NP). The NP is
                  the owner of the IP transport equipment. The SP naturally provides
                  end-user services and may or may not be the same entity as the NP.
                  For example the SP could be an UMTS mobile operator, leasing
                  transport capacity from an IP Network Provider. The leased capacity
                  inter-connects the Access Gates of the SP and is formalized by a
                  SLSs, which are part of a Service Level Agreement between NP and SP
                  (see section 5.2 ôQC-to-NMS interfaceö for more details).
               
                  The IP network is DiffServ enabled and therefore capable of
                  providing e.g. IP virtual leased line services. These IP VLLs are
                  specified by DiffServ Service Level Specifications (SLSs), which are
                  the technical part of the SLA.
               
                  QoS provisioning for individual flows is done by a two-step
                  approach. First step is to provision the capacity in the network by
                  provisioning bandwidth pipes between the ingress and egress points
                  of the IP network by means of SLSs. The second step is to perform
               
                  Buchli et al. Informational - Expires August 2002               10
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  admission control for microflows, i.e. checking whether they still
                  fit in the bandwidth pipe. This admission control function is done
                  by the QoS Controller.
               
                  The end-user QoS provisioning is described in detail below. Steps 1)
                  and 2) are the pre-provisioning steps for aggregate bandwidth pipes
                  (SLS). Steps 3) and 4) are the per-microflow signaling and admission
                  control steps.
               
                  1) The QoS Controller requests one or more bandwidth pipes (i.e.
                  virtual leased lines) to the NMS. These bandwidth pipe IP services
                  are specified as SLSs and are requested over an SLS interface or
                  they are negotiated off-line, resulting in a paper contract SLA (in
                  case NP and SP are distinct legal entities). The capacity of the
                  bandwidth pipes is based on some kind of traffic prediction process.
                  The SLSs are stored in databases in the QoS Controller and the NMS.
               
                  2) The NMS triggers a traffic management process in order to
                  provision the required resources (SLSs) in the network. This may
                  involve reconfiguring one or more network elements. The traffic
                  conditioning block in the edge routers are configured to police the
                  bandwidth pipes. Thus, the traffic is policed on an aggregate base.
               
                  3) The application (e.g. VoIP) at the end-host, requiring a
                  connection with QoS guarantees to another host or server, signals
                  the QoS request to the QoS Initiator. This signaling may be access
                  technology dependent. The QoS initiator performs the mapping to a
                  technology independent format and signals the QoS request to the QoS
                  Controller by the NSIS protocol.
               
                  4) The QoS Controller performs admission control for the QoS
                  request. It determines whether sufficient capacity is available in
                  the bandwidth pipes that are defined by the SLSs. The QC will return
                  an admit or reject message. Note, that this step does not involve
                  any configuration of network elements. If the flow has been admitted
                  the QoS Initiator will configure the Access Gate in order to police
                  the microflow.
               
                  This end-user QoS provisioning approach provides a clear distinction
                  between the provisioning of resources in the transport network and
                  the admission of per-microflow QoS requests. The per-flow QoS
                  signaling can therefore be kept simple since the complexity resides
                  mainly in the resource provisioning in the network and specification
                  of the bandwidth pipes (i.e. SLSs). The provisioning may be static
                  or semi-dynamic. The provisioning is anyhow already in place when
                  the per-flow QoS request arrive.
               
                  This two-step approach is also visible in the way the traffic is
                  policed. The edge router polices per SLS (bandwidth pipe), and
                  hence, on aggregated traffic. The Access Gate polices per-microflow.
                  The main point here is that the DiffServ network is not (required to
                  be) per micro-flow aware. The DiffServ network operator only
               
                  Buchli et al. Informational - Expires August 2002               11
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  provides QoS guarantees to the (SLA/SLS contracted) long-term
                  aggregate IP services such as IP virtual leased lines.
               
                  Above we made abstraction of the QoS class and QoS parameters to be
                  signaled. This is discussed in more detail below, but it is
                  instructive to make the following key observation at this point.
               
                  The main objective is to keep the NSIS signaling protocol between QI
                  and QC as simple as possible, certainly if it should be extended to
                  QC-to-QC inter-domain scenarios. Basically, the information to be
                  signaled is an indication of the QoS class plus a required
                  throughput R (peak rate, token rate, etc) for this particular QoS
                  class.
               
                  Indeed, provided the QoS class is determined by other means, the
                  required throughput is the main parameter needed by the QC to be
                  able to perform per-flow admission control (i.e. answering the
                  question whether there is still enough capacity in the QoS pipe SLS
                  for admitting e.g. R bandwidth units). We argue that there is no
                  need to signal delay values in the NSIS protocol (interface 3),
                  because the statistical delay bounds are already known and provided
                  by the SLSs. If the QC admits the request for R bandwidth units,
                  then the service will enjoy the delay bounds guaranteed by the SLS.
               
                  The remaining question is whether this approach can deal with
                  several service (QoS) classes. Suppose for example that there are
                  two QoS classes ôGoldö and ôSilverö. This could e.g. be used for the
                  offering of voice services with different quality. Another example
                  is to use the Gold QoS class for real-time, delay-sensitive services
                  and the Silver QoS class for elastic, non-delay sensitive services.
                  The latter only require a throughput guarantee. How is this handled
                  in the two-step approach described above?
               
                  First step: the pre-provisioning. The SLSs describing the bandwidth
                  pipes between the AGs may or may not contain edge-to-edge delay-
                  bound guarantees, corresponding respectively with gold and silver
                  type of services. The Gold and Silver SLSs are realized by
                  respectively the DiffServ Virtual Wire PDB and Assured Rate PDB.
               
                  Second step: per-flow signaling. Clearly the signaling between host
                  and QI (interface 1) must indicate whether the requested service is
                  gold or silver. The QoS class could also be implicitly derived from
                  the type of service (e.g. voice). Besides the QoS class the user
                  must at minimum also signal the required throughput.
               
                  In any case, the QI knows the appropriate QoS class and the required
                  throughput.
               
                  What remains to be decided is what information is signaled between
                  QI and QC. If the same QC is allowed to manage as well Gold as
                  Silver SLSs, then the QI needs to signal the required QoS Class. If
                  a QC only manages one type of SLSs, corresponding with one QoS
                  class, then the QI decides (based on QoS class information) which QC
               
                  Buchli et al. Informational - Expires August 2002               12
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  he has to request resources and signals (only) the required
                  throughput. It is for further study to decide whether both
                  approaches should be possible and able to inter work.
               
               
               5.2 Protocol interfaces
               
                 5.2.1 Host to QoS Initiator
               
                  The host to QoS Initiator protocol interface will in most cases
                  depend on the access technology that is used. Due to the variety of
                  access QoS technologies it is to be expected that there will not be
                  one single protocol used over this protocol interface.
               
                  The QoS Initiator is the entity that triggers the actual QoS setup
                  in the core network. There are several possibilities how the host
                  can trigger the QoS Initiator.
               
                  1) The QoS Initiator may be integrated in a web-host or an outbound
                  SIP proxy. In the first case the end-user may e.g. use a webpage in
                  order to specify the service he/she would like to use. The web host
                  may then initiate a QoS connection. In the latter case, the host may
                  piggyback the QoS information on the session setup signaling. More
                  precisely, QoS information may be carried in SDP [7] and may be
                  interpreted by the SIP proxy, which will trigger the QoS setup in
                  the network.
               
                  2) The host uses an access specific layer 2 or 3 protocol. This is
                  e.g. an RSVP-derived protocol for PacketCable networks and the
                  Packet Data Protocol (PDP) for UMTS networks. For xDSL broadband
                  access a mechanism based on ATM Virtual Connections (VC) maybe used.
                  The AG intercepts this QoS signaling and forwards it to the QoS
                  Initiator. In this way the access specific QoS signaling is coupled
                  to the generic QoS setup in the core.
               
                  This protocol interface is within the scope of NSIS in the sense
                  that existing access signaling protocols should be assessed whether
                  they contain the minimum set of parameters that are required at the
                  QoS Initiator in order to map them to the generic signaling protocol
                  between the QoS Initiator and the QoS Controller. Of course, the
                  first step should be to specify this minimum set of parameters
                  required for the generic signaling protocol.
               
               
                 5.2.2 QoS Initiator to Access Gate
               
                  The protocol interface between the QI and the AG is used to
                  configure the AG such that it correctly installs per-flow policers.
                  In order to configure the policer a flow identifier is required
                  (e.g. five-tuple) and a traffic descriptor (e.g. token bucket
                  parameters). Optionally an indication for DiffServ packet marking
                  may be signaled (i.e. the DiffServ Code Point value).
               
               
                  Buchli et al. Informational - Expires August 2002               13
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  This protocol interface may be e.g. COPS [4] or a future MIDCOM [13]
                  protocol. Hence, this protocol interface is outside the scope of
                  NSIS.
               
               
                 5.2.3 QoS Initiator to QoS Controller (NSIS)
               
                  The protocol interface between the QoS Initiator and the QoS
                  Controller is discussed in section 6. This protocol is generic in
                  the sense that is technology independent. The QI is responsible for
                  mapping the access technology dependent user QoS request on this
                  protocol.
               
                  This protocol interface is certainly within the scope of NSIS.
               
               
                 5.2.4 QoS Controller to Network Management System (NMS)
               
                  A Service Level Agreement (SLA) is a legal agreement between a
                  customer and a provider. The technical part of the SLA is called a
                  Service Level Specification (SLS). The SLS specifies capacity and
                  QoS guarantees between one or more ingress and egress points of a
                  network. The SLS also specifies the availability and reliability of
                  the bandwidth service. The services specified in an SLS usually stay
                  in place for a long duration (e.g. days or months) and their setup
                  (time between the request of the service from the customer and the
                  availability) will not be real-time. The resources needed to fulfill
                  the SLS may be provisioned by means of traffic engineering. In case
                  the IP network is a DiffServ domain, the SLS may be implemented with
                  a PDB [6], e.g. a virtual wire or assured rate PDB.
               
                  Remark that it is not required for the architecture to automate this
                  interface. Indeed the SLA may be negotiated off-line yielding full
                  static SLS pipes between the Access Gates. It may however evolve to
                  an automated, (to-be-standardized) interface.
               
                  It is argued that automation and standardization of this SLS
                  interface may yield two key advantages for QoS provisioning. First,
                  it may be used to semi-dynamically negotiate SLSs. For example, if
                  the QoS Controller has to block too many calls between two AGs, the
                  QC may trigger the NMS for more resources on a dynamic basis.
                  Second, the interface may be used to exchange monitoring
                  information. In other words, the NMS may send information about e.g.
                  the current traffic load in the bandwidth pipe that is specified by
                  the SLS. The monitoring information applies to the traffic aggregate
                  SLSs. The QC may use this monitoring information to cross check
                  whether the currently admitted flows (and their throughput)
                  corresponds with the actual traffic load in the bandwidth pipe SLSs.
                  An SLS template has been specified by the European IST-project
                  Tequila [9] in order to facilitate for both functions.
               
                  Finally note that in figure 3 the SLS interface is shown as a line
                  between the QC and NMS. This is a somewhat simplified view because
               
                  Buchli et al. Informational - Expires August 2002               14
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  in practice, the service provider owning the QC will also dispose of
                  an NMS for managing his equipment (e.g. Access Gates). Thus an SLS
                  interface will rather be implemented between two NMSÆs of providers.
                  These NMSÆs each have their SLS-database and the QC has access to
                  the NMS of the service provider for executing the policy-based
                  admission control decision.
               
                  This protocol interface may be in scope of NSIS.
               
                 5.3 Evolution scenario
               
                  In the previous section it was assumed that the end-host and QI were
                  two separate entities. This is because each type of access network
                  has its own QoS signaling protocol. The QI couples the access
                  dependent QoS signaling with the generic NSIS signaling in the core
                  (i.e. between QI and QC). Hence, in the short/medium-term the NSIS
                  protocol will be used between the QI and QC and an access technology
                  dependent protocol will be used between the host and the QI.
               
                  However, once an NSIS protocol has been specified and deployed
                  between QI and QC the access networks may gradually start to adopt
                  NSIS signaling. This implies that the QoS Initiator becomes
                  integrated in the end-host and that the NSIS protocol is also used
                  to setup QoS in the access. Of course, this is an evolution scenario
                  since there is a large installed base of cable, UMTS, xDSL access
                  networks only supporting their own QoS signaling methods.
               
                  Hence, in the long-term the NSIS signaling protocol may be supported
                  by the end-host (acting as QoS Initiator) and may also be used for
                  QoS signaling in the access network, realizing effectively end-to-
                  end (NSIS) QoS signaling.
               
               
               6. Requirements on the QoS Initiatorûto-QoS Controller interface
               
                  Per-flow QoS requests are mapped onto an SLS. Hence, most of the
                  complexity resides in the specification and provisioning of SLSs.
                  This results in a small set of requirements for the end-user QoS
                  signaling.
               
                  The QoS Initiator must map the parameters from the host-to-QI
                  interface on the QoS Initiator-to-QoS Controller (NSIS) protocol.
               
                  This section discusses the signaling requirements and parameter
                  groups that need to be signaled.
               
               
               6.1 Signaling requirements
               
                  1) The protocol should be lightweight.
                  The required processing power and memory consumption per QoS request
                  should be very small at the QoS Controller such that large amounts
                  of reservation requests can be processed per time unit. The protocol
               
                  Buchli et al. Informational - Expires August 2002               15
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  can be lightweight since the complexity resides in the pre-
                  provisioning of resources by means of SLSs.
               
                  2) The time to setup a QoS connection should be constrained to one
                  or a few round trip times.
                  This may be necessary for a telephony application because this
                  requires a small call setup delay. Short set up times can be
                  achieved by the two-step approach discussed earlier in this draft,
                  i.e. pre-provision bandwidth pipes by means of SLSs and map flow in
                  these bandwidth pipes.
               
                  3) Support of priority
                  A minimal support of priority and preemption in case of congestion
                  may be needed in the signaling or in the class description.
               
                  4) Immediate notification of QoS failure
                  The signaling must allow the users to be notified in case of QoS
                  failure or violation. This notification must be immediate if no
                  local recovery action is taken. The notification should occur when
                  local recovery actions are taken. This requirement is due to the
                  high reliability of the service that needs at least to make the user
                  know in case the QoS is no more guaranteed.
               
                  5) Both in-band and out-of-band signaling should be supported. This
                  implies that the QoS Initiator and QoS Controller may not be located
                  on the data path of the media flow. See e.g. the UMTS use case. The
                  main advantage of out-of-band signaling is that it avoids the need
                  to upgrade (edge) routers with e.g. the NSIS protocol. Indeed the
                  QCs can be deployed on existing (DiffServ) IP networks. In other
                  words, the network needs only to provision bandwidth pipes (e.g. by
                  means of DiffServ PDBs) while the QoS Controller performs per-flow
                  admission control into these pipes and processes the per-flow (NSIS)
                  signaling. Therefore, the NSIS protocol MUST allow for interworking
                  between both in-band and out-of-band signaling approaches for
                  (gradual) deployment reasons.
               
                  6) The protocol should be independent of core transport technology
                  as opposed to the access part where the transport and QoS are
                  technology specific. Because of this there is a need for
                  interworking between the QoS in the access network with the QoS in
                  the core network in order to offer end-to-end QoS (i.e. from host to
                  host).
               
                  7) The signaling information should be independent from the protocol
                  that carries it.
                  Different protocols may be used but the semantics should be the
                  same. The information semantics of the host-to-QI protocol must be
                  mapped on a QI-to-QC protocol. This mapping should take place in the
                  QoS Initiator. This couples the technology dependent signaling
                  protocols in the access with a generic protocol in the core. In
                  order to do this a minimal set of protocol parameters that need to
                  be mapped should be specified.
               
               
                  Buchli et al. Informational - Expires August 2002               16
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
                  8) Multicast consideration should not impact the protocol complexity
                  for unicast flows.
                  Multicast support is not considered as a priority, because the
                  targeted interactive multimedia services are mainly unicast. For
                  this reason, if considered in the solution, multicast should not
                  bring complexity in the unicast scenario.
               
                  9) Effective support of unidirectional reservations
                  Bidirectional reservations are considered as almost impossible in a
                  multidomain configuration due to the unidirectional nature of IP. So
                  bidirectionnal reservations are considered as exceptional if not out
                  of the scope of the protocol.
               
                  10) the mobility aspects should have no impact on the NSIS protocol
                  A QoS controller should not be affected by mobility issues. In UMTS
                  networks, the users has an anchor point in the GGSN, and thus does
                  not require mobility support.
               
                  11) Optimization for interactive multimedia services
                  The SIP/H.323 applications are foreseen as the main drivers for end
                  to end QoS solutions. NSIS protocols should be designed in order to
                  be optimised for such traffics.
               
                  12) Support for different service levels
                  The protocol should be able to support different service levels for
                  a service class. This may, for instance, be used in relation to
                  olympic service classes ("gold", "silver" and "bronze")
               
               
               6.2 Requirements on protocol content
               
                  The per-flow QoS requests are mapped onto the bandwidth pipe, which
                  is specified by an SLS. These pipes may provide statistical
                  guarantees such as delay and packet loss bounds (depending on the
                  QoS class). In order to invoke per-flow QoS services the only
                  parameter needed is a required rate, a means to identify the data
                  path (mapping on SLS) and eventually a reservation identifier.
               
                  1) Microflow/reservation description
                  The signaling should allow the request to describe the microflow
                  whose QoS would be guaranteed by giving at least the source and
                  destination IP addresses of the media flow. In case the QC is
                  stateful (per microflow) there may be a need to include a unique
                  reservation identifier (e.g. QI identifier+counter) such that in
                  case of e.g. a tear down message the reservation can be easily
                  identified in the QC.
               
                  2) Traffic descriptor
                  The required peak rate must be signaled. Optionally the traffic
                  parameters may be expressed in terms of token bucket parameters
                  (similar to the TSpec in RSVP).
               
               
               
                  Buchli et al. Informational - Expires August 2002               17
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
               6.3 Open issues
               
                  Two points are left as open issues:
               
                  1) The protocol may be stateful or stateless.
                  Because of the two-level approach, statefulness needs to be
                  considered both for the pre-provisioned pipes and for the
                  microflows.
                  Clearly, per QoS-class state will need to be maintained by the NMS
                  and the QC; so the (long-term) bandwidth pipe reservations always
                  should be stateful.
               
                  It is not clear yet whether per microflow state should be maintained
                  by the QC.
                  A stateful approach allows simple implementation of per-flow
                  notification of QoS violation and priority/preemption. This may be
                  feasible in some parts of the network because the two-step approach
                  strongly reduces the state information that needs to be kept. Still,
                  in core networks the number of reservations may be too large to use
                  a stateful approach. A stateful approach can keep hard-state or
                  soft-state. Regardless of the fact whether hard-state or soft-state
                  is used, we see a possible need for explicit refresh/feedback
                  messages that may be used for teardown and/or performance
                  notification (performance level and/or violation). Note that these
                  messages may be per-flow or per-class.
                  A stateless approach may simply decrement/increment capacity on pre-
                  provisioned bandwidth pipes without keeping per-flow state. In this
                  case, the information required for priority support and/or QoS
                  failure notification may be implemented on a per-class basis. Note
                  that in this case, only one setup message should be sent in order to
                  avoid duplicate reservation. Notification messages should be clearly
                  distinguishable as such in order to avoid unnecessary or unwanted
                  allocation or deallocation of resources.
               
                  2) Grouping of microflows
                  As a consequence of the optimization for the interactive multimedia
                  services, the signaling should allow one unique request for several
                  micro flows having the same origination and destination IP
                  addresses. This is usually the case for multimedia SIP calls where
                  the voice and video micro flows follow the same path. This grouping
                  of requests allows optimization of the QoS processing. Note that
                  this may be detrimental for the call setup time. The use of grouping
                  for microflows may be restricted to teardown and/or notification
                  messages when call setup time is a concern.
               
               
               7. Security Considerations
               
                  This draft does not identify other security aspects than those
                  described in [8].
               
               
               
                  Buchli et al. Informational - Expires August 2002               18
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
               8. Conclusions
               
                  Based on the use cases of an interconnection scenario of PSTN
                  trunking gateways and an interconnection scenario between a UMTS
                  access network and an IP core network, a general architecture is
                  proposed and the different protocol interfaces where identified.
                  These are between the:
               
                  1) host and the QoS Initiator,
                  2) QoS Initiator and the Access Gate,
                  3) QoS Initiator and the QoS Controller,
                  4) QoS Controller and the Network Management System.
               
                  The QoS signaling in the access is usually technology dependent.
                  However, the QoS signaling in the core should be technology
                  independent. The signaling protocol requirements and the parameter
                  groups to be signaled between the QoS Initiator and the QoS
                  Controller where discussed in this draft.
               
                  The proposed architecture involves two steps in QoS provisioning:
               
                  1) Provisioning of bandwidth pipes between the ingress and egress
                  points of the IP core network by means of SLSs. This involves
                  configuration of network elements by a Network Management System.
               
                  2) Admission control of per-flow QoS request in the pre-provisioned
                  bandwidth pipes. In other words, a functional entity in the network
                  checks if the usage of the bandwidth pipe between the ingress and
                  egress points of the network does not exceed the capacity specified
                  in the SLS. Hence, this step does not involve any configuration of
                  network elements.
               
                  The following recommendations are made towards the NSIS working
                  group:
               
                  1) A first priority for NSIS should be the signaling interface
                  between the QoS Initiator and the QoS Controller. This is completely
                  in line with the recommendation in [8].
               
                  2) The protocol between the host and the QoS Initiator is access
                  technology dependent. Therefore, NSIS should study the different
                  access signaling protocol and assess whether they contain the
                  minimal set of protocol parameter groups (that have to be defined in
                  step 1). If not, changes may be proposed for these access signaling
                  protocols.
               
                  3) The SLS interface between the QoS Controller and the NMS is used
                  for SLS negotiation and for the exchange of SLS monitoring
                  information. The SLS negotiation may be off-line by means of a paper
                  contract or may be semi-dynamically signaled. The monitoring aspect
                  of SLSs is very important and requires that the protocol between the
                  NMS and the QC is able to exchange such information. Therefore, NSIS
                  may consider adding this signaling interface to their scope.
               
                  Buchli et al. Informational - Expires August 2002               19
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
               
               
               9. Acknowledgment
               
                  The authors would like to acknowledge Alban Couturier for his
                  contributions to the QoS signaling requirement section.
               
                  The authors would also like to acknowledge Christian Jacquenet,
                  George Pavlou, Richard Egan, David Griffin, Panos Georgatsos, Pim
                  Van Heuven, Eleni Mykoniati and other participants in the TEQUILA
                  project for their input and reflection on this work.
               
               
               References
               
                  1  RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.
               
                  2  RFC 2205 Braden, R. et al., "Resource ReSerVation Protocol (RSVP)
                     - Version 1 Functional Specification", RFC 2205, September 1997.
               
                  3  RFC 2223 Postel, J. and Reynolds, J., "Instructions to RFC
                     Authors", RFC 2223, October 1997.
               
                  4  RFC 2748 Boyle, J. et al., "The COPS (Common Open Policy Service)
                     Protocol", RFC 2748, January 2000.
               
                  5  RFC 3015 Cuervo, F. et al., "Megaco Protocol Version 1.0", RFC
                     3015, November 2000.
               
                  6  RFC 3086 Nichols, K. and Carpenter, B., "Definition of
                     Differentiated Services Per Domain Behaviors and Rules for their
                     specification", RFC 3086, April 2001.
               
                  7  Bos, L. et al., "A Framework for End-to-End User Perceived
                     Quality of Service Negotiation", draft-bos-mmusic-sdpqos-
                     framework-00.txt, Work in Progress, November 2001.
               
                  8  Brunner, M. et al., "Requirements for QoS Signaling Protocols",
                     draft-brunner-nsis-req-00.txt, Work in Progress, November 2001.
               
                  9  Goderis, D. et al., "Service Level Specification Semantics,
                     Parameters and negotiation requirements", draft-tequila-sls-
                     02.txt, Work in Progress, February 2002.
               
                  10 Grossman, D., "New terminology for diffserv", , draft-ietf-
                     diffserv-new-terms-08.txt, work in progress, January 2002.
               
                  11 Sidebottom, G. et al., "SS7 MTP3-User Adaptation Layer (M3UA)",
                     draft-ietf-sigtran-m3ua-12.txt, Work in Progress, Febuary 2002.
               
               
               
                  Buchli et al. Informational - Expires August 2002               20
                               QoS signaling architecture, interfaces   February 2002
                                             and requirements
               
               
                  12 Westberg, L. et al., "Resource Management in Diffserv (RMD)
                     Framework", draft-westberg-rmd-framework-01.txt, Work in
                     Progress, February 2002.
               
                  13 IETF Middlebox Communication (MIDCOM) working group,
                     http://www.ietf.org/html.charters/midcom-charter.html/
               
                  14 IST-Tequila project http://www.ist-tequila.org/
               
               
               
               
               Author's Addresses
               
                  Maarten Buchli
                  Alcatel
                  Network Strategy Group
                  Francis Wellesplein 1
                  B-2018 Antwerpen           Phone: +32 3 2407081
                  BELGIUM                    Email: maarten.buchli@alcatel.be
               
                  Danny Goderis
                  Alcatel
                  Network Strategy Group
                  Francis Wellesplein 1
                  B-2018 Antwerpen           Phone: +32 3 2407853
                  BELGIUM                    Email: danny.goderis@alcatel.be
               
                  Sven Van den Bosch
                  Alcatel
                  Network Strategy Group
                  Francis Wellesplein 1
                  B-2018 Antwerpen           Phone: +32 3 2408103
                  BELGIUM                    Email: sven.van_den_bosch@alcatel.be
               
                  Juan-Carlos Rojas
                  Alcatel
                  Next Generation Networks Division
                  Le Mail
                  F-44708 Orvault Cedex      Phone: +33 2 51781282
                  FRANCE                     Email: juan-carlos.rojas@alcatel.fr
               
                  Stefan Custers
                  Alcatel
                  Next Generation Networks Division
                  Francis Wellesplein 1
                  B-2018 Antwerpen           Phone: +32 3 2409071
                  BELGIUM                    Email: stefan.custers@alcatel.be
               
               
                  Buchli et al. Informational - Expires August 2002               21