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

Versions: 00                                                            
   Internet Draft                                        Robert Hancock
                                                       Eleanor Hepworth
                                                        Andrew McDonald
                                            Siemens/Roke Manor Research
   Document: draft-hancock-nsis-sender-
   receiver-00.txt
   Expires: April 2003                                     October 2002


              Sender and Receiver Orientation Issues in NSIS
                draft-hancock-nsis-sender-receiver-00.txt

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 NSIS working group is considering protocols for signaling for
   resources for a traffic flow along its path in the network. The
   requirements for such signaling are being developed in [2] and a
   framework in [3].

   It is clear from existing work that there are many interrelated
   issues with NSIS signaling, concerning the respective roles of the
   two ends of the communication path. These issues include route
   finding, authorisation, state management requirements, localization
   of negotiation, and so on. The wide variety of problems involved
   hinders progress in deciding what approach NSIS should adopt. This
   Internet Draft attempts to provide a summary of these issues and
   suggests a way of structuring further analysis. It is not expected
   that this document should have a long term existence.



Hancock et al.           Expires - April 2003                 [Page 1]


                     NSIS: Sender/Receiver Issues         October 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 [4].

Table of Contents

   1. Introduction, Terminology, and Scope...........................2
     1.1 Data and Signaling Flows ...................................2
     1.2 Status of Existing Protocols ...............................4
     1.3 Protocol Layering Assumptions ..............................4
   2. Constraints on Sender/Receiver Orientation.....................5
     2.1 Signaling Message Routing ..................................5
     2.2 User Application Triggering ................................5
     2.3 Renegotiation ..............................................6
     2.4 'Service' Authorization ....................................6
     2.5 Localized Signaling Support ................................8
     2.6 Protocol - Protocol Interactions ...........................9
     2.7 Multicast Support ..........................................9
     2.8 Something Unpleasant about NAT .............................9
     2.9 Summary ...................................................10
   3. Possible Approaches...........................................10
     3.1 Fix on One Paradigm .......................................10
     3.2 Allow Both Paradigms ......................................11
     3.3 Choose Separately for Each Protocol Component .............11
     3.4 Implications of a Layered Choice ..........................12
   4. Additional Considerations.....................................12
     4.1 Bidirectional Reservations ................................12
     4.2 Path-Decoupled Signaling ..................................13
   5. Conclusions...................................................14
   Acknowledgments..................................................15
   Author's Addresses...............................................15
   Full Copyright Statement.........................................15


1. Introduction, Terminology, and Scope

   Unless otherwise stated, this document follows the terminology given
   in the current NSIS framework [3].

1.1 Data and Signaling Flows

   For the bulk of this document, we are concerned with path-coupled
   signaling for a single unidirectional flow, as shown in Figure 1
   (additional considerations are given in section 4). The node that is
   sending the user data packets is called the 'sender' and the node



Hancock et al.           Expires - April 2003                 [Page 2]


                     NSIS: Sender/Receiver Issues         October 2002

   sinking them the 'receiver'; these packets pass through one or more
   routers.

        +--------+        +-+        +-+        +-+        +--------+
        | Sender |------->|R|------->|R|------->|R|------->|Receiver|
        +--------+        +-+        +-+        +-+        +--------+

                  ----------> = Flow of user data packets

                       Figure 1: Sender and Receiver

   In the case of path-coupled NSIS signaling, there are signaling nodes
   (NSIS entities) along the data path. The NSIS initiator (NI)
   notionally controls the signaling (e.g. at application request),
   whereas the NSIS responder (NR) terminates the signaling at the far
   end; there may be one of more NSIS forwarders (NF) between the two.

   The NI and NR do not have to be colocated with sender and receiver
   (e.g. they could be at first/last hop access routers); nor do they
   have to be the same 'way round' as the sender and receiver. This
   leads to two different cases for analysis. Figure 2 shows the 'sender
   initiated' case, and Figure 3 shows the 'receiver initiated' case.

        +--------+        +--+       +--+       +--+       +--------+
        | Sender |------->|NI|------>|NF|------>|NR|------>|Receiver|
        +--------+        +--+       +--+       +--+       +--------+
                             ========>  ========>

                     ========>  = Flow of NSIS 'control'

                        Figure 2: Sender Initiation



        +--------+        +--+       +--+       +--+       +--------+
        | Sender |------->|NR|------>|NF|------>|NI|------>|Receiver|
        +--------+        +--+       +--+       +--+       +--------+
                             <========  <========

                     ========>  = Flow of NSIS 'control'

                       Figure 3: Receiver Initiation

   One of the basic open issues in NSIS is whether one or both of these
   models should be supported, and in either case, what is the real
   difference in functionality between the NI and NR; to put it another




Hancock et al.           Expires - April 2003                 [Page 3]


                     NSIS: Sender/Receiver Issues         October 2002

   way, how 'directional' is the relationship between NSIS entities
   (which up to now has not really been defined).

   It is the purpose of this document to gather together some of the
   information about this subject and propose a way forward.

1.2 Status of Existing Protocols

   The principle existing path-coupled signaling protocol is RSVP [5].
   RSVP is commonly described as 'receiver initiated', although there
   are some subtleties in this categorization.

   From the point of view of the act of resource reservation, RSVP is
   clearly receiver initiated, in that the receiver is responsible for
   generating the RESV message which actually defines the QoS that the
   receiver wants for incoming traffic. This RESV message can also be
   accompanied with security-related policy information to support the
   request (see [6]). The primary motivation behind adopting receiver
   initiation for resource reservation appears to have been multicast
   support, as described in [7].

   On the other hand, key elements of RSVP operation (RESV routing and
   route change detection) depend on the PATH message which is generated
   by the sender, and can be seen as triggering the RESV message (at
   least the first one). This sender-generated message also contains
   QoS-related information (and can even contain policy elements).

   We can therefore see RSVP as containing several functions, some
   sender oriented and some receiver oriented. It might be that this
   distinction should be carried over into a successor protocol.

1.3 Protocol Layering Assumptions

   The working assumption in the NSIS group is the signaling protocol
   should be 'layered' in two parts (see section 4 of [3] for more
   details), and this is consistent with several protocol proposals,
   such as CSTP/ALSP [8] and others too provocative to mention here.

   In this document, we refer to these layers as follows:
    *) The 'NSIS Base Protocol' (NBP), handling message routing aspects
   specific to path-coupled signaling; it may include transport-layer-
   like functionality (reliability, congestion control and so on) or be
   layered on an existing transport protocol.
    *) 'A Signaling Application Protocol' (ASAP), a 'placeholder' for
   one of many possible protocols which handle particular signaling
   applications (QoS, middlebox control, and so on).




Hancock et al.           Expires - April 2003                 [Page 4]


                     NSIS: Sender/Receiver Issues         October 2002

2. Constraints on Sender/Receiver Orientation

   Depending on the particular NSIS function (or specific signaling
   application function) under consideration, it may be much easier to
   implement it in a sender or receiver 'oriented' way. This section
   summarizes these various constraints or influences.

2.1 Signaling Message Routing

   Regardless of the particular signaling application in question, path-
   coupled signaling requires the capability of message routing along
   the path from sender to receiver. It appears that there are only two
   methods for the signaling protocol to acquire awareness of the route:
    *) Using a PATH mechanism similar to RSVP.
    *) Using local topology information (e.g. from a routing protocol,
   or local configuration).

   Signaling message routing, which is a function of the NBP layer,
   should therefore be sender oriented, possibly with the ability to use
   additional information sources if available.

   A related question is whether signaling messages need to be routed
   with or against the data flow (or both). (So far as we can tell, the
   NBP layer only sends and receives messages over a single NSIS hop, so
   the question only applies to the ASAP layer. It applies both to
   'real' signaling application messages and probably also to
   application-specific error notifications.) If messages need to be
   routed against the data flow, this has implications for the need to
   store reverse-path message routing state at intermediate nodes.

   The conclusion therefore seems to be that the NBP layer should be
   able to operate in a sender-oriented mode, but what state it needs to
   store depends on ASAP layer requirements.

2.2 User Application Triggering

   Ultimately, the NSIS signaling is supporting the requirements of some
   user application (e.g. a VoIP or other media capability). It is
   likely that sometimes, only one 'party' will have a clear view on
   what to request, e.g. what is the appropriate QoS, or even what are
   the flow identification characteristics (port numbers or flow labels
   may be allocated only at the sender).

   Even if both ends know, still one end probably knows first and
   communicates the information via upper layer exchanges; therefore,
   fixing sender or receiver orientation for NSIS signaling may impose
   additional roundtrip delays compared to an 'optimised' solution.



Hancock et al.           Expires - April 2003                 [Page 5]


                     NSIS: Sender/Receiver Issues         October 2002


   The constraints here are probably both
    *) Signaling application specific, and
    *) User application specific.
2.3 Renegotiation

   There has been some discussion (requirement 5.6.3 of [2] and section
   3.3.2 of [3]) of the need for flexibility in which entities can
   renegotiate aspects of a reservation - for example, whether the
   sender or receiver should be able to do this, or the initiator or
   responder, or whether it should be possible from within the network.

   This is probably a question which depends on the ASAP layer. If
   additional flexibility has to be supported for renegotiation compared
   to initial reservation setup, then this will be an additional source
   of complexity. Note that some of the motivation for this flexibility
   is (presumably) to allow localized renegotiation, which is also
   discussed in section 2.5.

2.4 'Service' Authorization

   When any 'resource' is being requested from the network, in some
   cases the use of this resource must be authorised (or somehow
   verified to be compatible with a network's internal policy
   requirements).

   It is a hard question to work out how authorisation approaches might
   impact on the sender/receiver orientation aspects. For example, it is
   possible that current inter-provider peering agreements would favour
   a 'sender-initiated' authorisation approach, since typically the
   traffic originator 'pays' for traffic. On the other hand, in mobile
   environments, the mobile user may be prepared to authorise a resource
   request for both directions; a firewall application may only accept
   resource requests from one side.

   Therefore, the service authorisation constraints on sender/receiver
   orientation are both
    *) Signaling application dependent, and
    *) Network policy dependent (although it may be the case that for
   any given signaling application, there is a single 'natural'
   authorisation direction). Indeed, even for a single path, the network
   policy may change at provider boundaries.

   One reason why sender/receiver authorisation has an impact on
   signaling flows is the state management aspects while a request is
   being authorised end to end. For example, Figure 4 shows a 'initiator
   authorised' signaling flow: messages flowing in the direction
   NI-->NF-->NR can carry their own authorisation data (they could even


Hancock et al.           Expires - April 2003                 [Page 6]


                     NSIS: Sender/Receiver Issues         October 2002

   carry it idempotently/statelessly), which could allow very simple
   authorisation processing at intermediate nodes.








         +--+                                                  |
         |NI|                                                  |
         +--+   1: Resource request (with                      |
             \  authorisation data) for                        |
              \ first segment of data path                     |
               \                                               |
                _|                                             |
                  +---+ 2: Authorisation verified by NF1       | T
                  |NF1| and request admitted; resource         | I
                  +---+ request propagated to next segment     | M
                      \                                        | E
                       \   3: Resource request for             |
                        \  second segment of data path         |
                         _|                                    |
                           +---+                               |
                           |NF2|                               V
                           +---+                               V
                                .                              V
                                 .                             V

            Figure 4: Message Flow for Initiator Authorisation

   However, the 'responder authorised' situation is more complex, since
   the actual authorisation data has to come from the remote end of the
   signaling exchange, and intermediate nodes may have to retain state
   waiting for this to arrive, as shown in Figure 5.

   The conclusion from this part of the discussion is that:
    *) Either the initiator or the responder might be responsible for
   authorisation aspects (depending on the discussion above), but
    *) If the responder is responsible, the NBP will have to handle
   messages in both directions, and intermediate nodes will have to
   handle more local state storage.







Hancock et al.           Expires - April 2003                 [Page 7]


                     NSIS: Sender/Receiver Issues         October 2002

               +--+
               |NI|                                            |
               +--+                                            |
                   \  1: Resource request for                  |
                    \ first segment of path                    |
                     \                                         |
                      _|                                       |
                        +--+  2: Resource request              |
                       {|NF|  propagated                       |
                       {+--+  to  next segment                 |
                       {    \                                  |
                       {     \   3: Resource request for       | T
       During steps    {      \  second segment of path        | I
       2 to 5:         {       _|                              | M
       NF awaiting     {         +--+                          | E
       authorisation   {         |NR|   4: NR generates        |
       information     {         +--+   authorisation info     |
       from NR         {        /                              |
                       {       / 5: Authorisation              |
                       {      /  information from NR           |
                       {    |_   for second segment            |
                       {+--+                                   V
                       {|NF|                                   V
                        +--+                                   V
                       .                                       V
                      .

            Figure 5: Message Flows for Responder Authorisation

2.5 Localized Signaling Support

   Technical approaches for localization of signaling have already been
   discussed in the context of RSVP, for example in [9] and [10]. There
   are several reasons why it may be desirable to localize the scope of
   some aspect of the signaling, such as:
    *) Only one endpoint may be generally NSIS aware (e.g. because the
   other endpoint has no motivation to implement it, or because it is a
   legacy device).
    *) Only one endpoint may be aware of the specific ASAP which is
   relevant.
    *) One endpoint may be mobile and wish to manage aspects of its
   reservations locally to improve handover performance.

   Regardless of the motivation, the end result is that in some
   scenarios, an endpoint will probably wish to carry out both sender
   and receiver oriented signaling over some local region of the
   network, i.e. for incoming and outgoing packets for a bi-directional
   session. Ideally this would be done both:


Hancock et al.           Expires - April 2003                 [Page 8]


                     NSIS: Sender/Receiver Issues         October 2002

    *) for the NBP layer (although we have said in 2.1 that this is
   hard), and
    *) for the ASAP layer.

   In practice, the mechanism for localizing signaling will be some kind
   of proxy, and the difficulty in the NBP layer is precisely the
   difficulty in locating the proxy using purely local signaling. Given
   the proxy location, however, the ASAP layer signaling between it and
   the end point then suffers from all the same constraints related to
   sender/receiver orientation as in the end to end case.

2.6 Protocol - Protocol Interactions

   As well as operating locally (in isolation), NSIS signaling will have
   to interact with other protocols, such as RSVP in other parts of the
   network. Also, several NSIS deployment scenarios consider NSIS
   interacting with itself in a 'layered' style, or end-to-end NSIS
   using edge-to-edge signaling for intradomain provisioning (see for
   examples sections 3.2 and 7 of [3]).

   In these circumstances, NSIS is at least partly at the mercy of these
   other protocols or other instances of itself, to be initiated and to
   respond in a compatible way at the protocol interworking boundary. In
   particular, to interwork with RSVP, NSIS signaling may have to be
   able to operate in compatible way (e.g. receiver oriented for
   reservation).

2.7 Multicast Support

   Multicast support is the primary justification for the receiver
   orientation of the reservation signaling in RSVP. The reason is that
   this naturally allows for progressive state merging from large
   numbers of receivers back towards the senders, thereby allowing
   better scalability. For the most general multicast case, this
   conclusion seems unchallenged (although restricted multicast
   scenarios, such SSM [11] or multicast with homogeneous receivers,
   other options may be possible).

   Multicast support is not an initial requirement for NSIS protocol
   work. However, in the future, it might be desirable to extend parts
   of NSIS to support multicast signaling applications, in which case
   particular sorts of receiver orientation should not be permanently
   excluded.

2.8 Something Unpleasant about NAT

   The existence of NATs poses some special problems for signaling
   protocols, since they change the header information in packets


Hancock et al.           Expires - April 2003                 [Page 9]


                     NSIS: Sender/Receiver Issues         October 2002

   downstream from the sender in a way which may not be predictable
   before the data flow along the path is actually active (e.g. if
   dynamic address sharing is taking place).

   The consequence of this is that, even if we would naturally imagine a
   certain signaling operation being controlled from the receiver, this
   may not be possible because the receiver does not know how to refer
   to the flow in the first place. Therefore, the signaling has to at
   least involve the sender as well, probably in cooperation with the
   receiver (and NAT) as well.

2.9 Summary

   The overall conclusion of this section is that there are all sorts of
   reasons why:
    *) Sender orientiation may be required for some functions or in some
   scenarios;
    *) Receiver orientation may be required for other functions or other
   scenarios;
    *) Sender and receiver orientiation have different costs and
   complexities (e.g. in state management or latency) associated with
   them.

   The choice between sender and receiver orientation therefore appears
   as a classic rock and hard place dilemma, especially given the
   natural desire to build a solution that is not overwhelmed by
   complexity or option negotiation.

3. Possible Approaches

   This section presents three possible approaches to resolving this
   conundrum.

3.1 Fix on One Paradigm

   Initially, the most attractive possibility would be to fix on a
   single paradigm and impose it throughout the NSIS work.

   However, it seems impossible to imagine that a single paradigm will
   support all the requirements and scenarios under discussion; even the
   baseline RSVP approach, summarized in 1.2, covers only some of the
   possibilities, and in some scenarios simpler sender-only solutions
   are possible. A wider set of options might also make incremental
   deployment (which could be a critical issue) more achievable.






Hancock et al.           Expires - April 2003                [Page 10]


                     NSIS: Sender/Receiver Issues         October 2002

3.2 Allow Both Paradigms

   The opposite approach is to allow everything - all aspects of NSIS -
   to be both sender and receiver oriented. The basic danger here is of
   overwhelming the NSIS protocols with excessive complexity, since they
   may well have to operate differently depending on which direction
   they are working in. It would also make it more difficult to
   implement a minimal subset of NSIS for particularly constrained
   environments.

   Even if the NSIS protocols could be specified and implemented, the
   variety of options would pose some operational problems. It might be
   that both sender and receiver would attempt to initiate the signaling
   protocol and cause a protocol collision (or indeed that neither of
   them would). The necessary remedy for this would be to introduce yet
   another component of the NSIS protocol, to negotiate which end should
   take the initiative.

3.3 Choose Separately for Each Protocol Component

   A third way is to select between sender and receiver orientation
   independently for each component; provided the inter-component
   interactions can be controlled, this should then allow better fitting
   of protocol behavior to the constraints identified above.

   Specifically, we could imagine the following:

   The NBP layer would be (universally) sender oriented, the same way as
   the RSVP PATH message (possibly also allowing for other peer
   discovery mechanisms and proxy usage).

   The ASAP layer would be either sender or receiver oriented, depending
   on the signaling application in question. There might even be
   different variants for different deployment scenarios (e.g. a sender-
   oriented intra-domain QoS signaling application, which worked with a
   receiver-oriented inter-domain counterpart at domain boundaries).

   The operation of the NBP and ASAP layers would be interdependent to
   some extent. The dependencies would include:
    *) A receiver-oriented ASAP would suffer from (at least) a single
   end-to-end delay, waiting for the NBP layer to complete establishing
   the signaling path. However, this delay is probably an unavoidable
   consequence of whatever constraints meant the ASAP was receiver-
   oriented in the first place.
    *) The NBP might unnecessarily store reverse-path state for a purely
   sender-oriented ASAP (in other words, one which required no receiver-
   to-sender messages). This could be fine tuned by allowing the ASAP to
   invoke the NBP in a mode which didn't store such state.


Hancock et al.           Expires - April 2003                [Page 11]


                     NSIS: Sender/Receiver Issues         October 2002


3.4 Implications of a Layered Choice

   Splitting the responsibility in this way and leaving the selection to
   the ASAP layer represents quite a significant shift in thinking
   compared to current protocols. There are therefore some dangers.

   The first danger is of excessive flexibility. On the other hand, the
   flexibility is a consequence of the NSIS requirements and
   constraints. This approach does allow simpler solutions in particular
   environments (e.g. for specific ASAP layers).

   The split decision probably has implications for the way state is
   managed between the layers, especially where different layers are in
   different protocol states in the interior of the network. This
   clearly needs further analysis.

   If the choice between sender and receiver initiation is really a
   matter for the ASAP layer, the implication is that the messages
   visible in the NBP should be somewhat neutral in content. The
   existing NSIS framework (section 4.3.2 of [3]) may be too specific in
   this regard. Also, the basic NI/NF/NR concepts may have to be split
   depending on the NBP/ASAP layer.

4. Additional Considerations

   The adoption of a split approach for sender/receiver orientation
   could have some implications for other aspects of NSIS-related work
   beyond the basic unicast path-coupled case. These are summarized
   here.

4.1 Bidirectional Reservations

   NSIS work (especially requirements work) has discussed the case of
   'bidirectional' reservations, in other words, signaling for both
   directions of a point-to-point data flow. The baseline approach for
   this feature (see section 3.2.7 of [3]) is to simply combine a pair
   of unidirectional reservations, which is then covered by the previous
   discussion.

   However, a 'true' bi-directional reservation (integrating the
   signaling for each direction) would also be interesting in some
   applications. Topologically, this would only be possible over a path
   segment that was symmetrically routed.

   Following the split layer approach of section 3.3, it seems that
   asking for bi-directional protocol within the NBP layer is not
   meaningful, since in general, even if the route is symmetric, NBP


Hancock et al.           Expires - April 2003                [Page 12]


                     NSIS: Sender/Receiver Issues         October 2002

   layer procedures have to operate asymmetrically while finding this
   out. However, it could be possible for the NBP layer to detect this
   symmetry (i.e. correlate the routes for incoming and outgoing flows)
   and provide this as an enhanced service interface to the ASAP layer.

   Whether the ASAP layer can or must use this capability to set up a
   bi-directional reservation using that interface is probably very much
   dependent on the signaling application and possibly scenario in
   question. It seems likely that the logical behavior (to do with state
   management, message sequences and so on) is the same as just a sender
   and receiver initiated reservation; however, the sending and
   reception of the messages in pairs might enable more efficient local
   processing.

4.2 Path-Decoupled Signaling

   Although NSIS does not currently have path-decoupled signaling in its
   scope, it is worth pointing out here some issues that may be special
   related to sender/receiver aspects in the path-decoupled case.

   The main issue with path-decoupled signaling is that once the
   signaling endpoints are not on the data path, it is no longer an
   unambiguous topological decision to categorize one of them as being
   related to the sender and the other to the receiver (see Figure 6).

         +--------+        +-+
         | Sender |------->|R|
         +--------+        +-+\
                               \
                                \
                        +--+     \       +--+
                        |NI|============>|NR|
                        +--+       \     +--+
                                    \
                                     \
                                      \+-+        +--------+
                                       |R|------->|Receiver|
                                       +-+        +--------+


                  ----------> = Flow of user data packets
                   ========>  = Flow of NSIS 'control'

                Figure 6: Path-Decoupled Signaling Topology

   If there is to be an attempt to re-use path-coupled NSIS signaling in
   this type of environment, and the signaling depends significantly on



Hancock et al.           Expires - April 2003                [Page 13]


                     NSIS: Sender/Receiver Issues         October 2002

   sender and receiver orientation, it will be necessary to work out how
   to match these concepts in the path-decoupled case.

   One approach to this would be to place the responsibility for 'path-
   orientation' in the NBP layer or its equivalent (which has to be
   modified anyway for the path-decoupled case to support off-path
   nodes). This layer will also have to have some more explicit
   (application layer?) interaction with the data sender and receiver,
   just to trigger the signaling process in the first place. However,
   once this is done, the ASAP layer (at least in terms of message
   exchanges) might operate in almost exactly the same way as in the
   path-coupled case.

5. Conclusions

   This document has no conclusions. However, it proposes a method for
   reasoning (possibly constructively) about the sender/receiver
   orientation possibilities. Implications for the requirements and
   framework, and consequences for path-decoupled signaling, have also
   been identified.


   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-04.txt (work in progress), August 2002

   3  Freytsis, I., R. E. Hancock, G. Karagiannis, J. Loughney, S. van
      den Bosch, "Next Steps in Signaling: Framework", draft-ietf-nsis-
      fw-00.txt (work in progress), October 2002

   4  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   5  Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
      Version 1 Functional Specification", RFC 2205, September 1997

   6  Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
      January 2000

   7  Braden, R. et al., "Integrated Services in the Internet
      Architecture: an Overview", RFC 1633, June 1994





Hancock et al.           Expires - April 2003                [Page 14]


                     NSIS: Sender/Receiver Issues         October 2002


   8  Braden, R., "A Two-Level Architecture for Internet Signaling",
      draft-braden-2level-signal-arch-00.txt (work in progress),
      November 2001 (expired)

   9  Gai, S. et al., "RSVP Proxy", draft-ietf-rsvp-proxy-03.txt (work
      in progress), March 2002

   10 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt
      (work in progress), May 2002

   11 Bhattacharyya, S. et al., "An Overview of Source-Specific
      Multicast (SSM)", draft-ietf-ssm-overview-03.txt (work in
      progress), March 2002



Acknowledgments

   The authors would like to thank all their colleagues and fellow
   participants in the NSIS working group for exposing the complexities
   and subtleties in this subject area.

Author's Addresses

   {Robert Hancock, Eleanor Hepworth, Andrew McDonald}
   Roke Manor Research
   Old Salisbury Lane
   Romsey
   Hampshire
   SO51 0ZN
   United Kingdom
   email: {robert.hancock|eleanor.hepworth|andrew.mcdonald}@roke.co.uk

Full Copyright Statement

   Copyright (C) The Internet Society (2002). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for



Hancock et al.           Expires - April 2003                [Page 15]


                     NSIS: Sender/Receiver Issues         October 2002

   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.






































Hancock et al.           Expires - April 2003                [Page 16]