Subject: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt

From: Bob Braden <[email-masked]>
Date: Wed, 13 Nov 2002 19:36:31 GMT

This message contains detailed comments on the Framework document. (To
make John L happy, I tried to include suggested alternative text in
places.)  It accompanies an overview message that tries to give
high-level comments.

Specific suggested changes are indicated below the changed lines, with
lines prefixed with "####".

  *>    Document: draft-ietf-nsis-fw-01.txt 
  *>    Expires: May 2003                                      November 2002
  *>     
  *>     
  *>                     Next Steps in Signaling: Framework 
  *>  
  *> Status of this Memo 
  *>     

  *>  
  *> 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]; this 

(No references allowed in an Abstract)

  *>    Internet Draft will propose a framework for such signaling. 
  *>     

"architectural framework" would be a little less vague than simply
"framework" here.

  *>    This initial version provides a model of the entities that take part 
  *>    in the signaling. It discusses the considerations that must be taken 
  *>    into account in developing the framework, particularly the options 
  *>    for the structure of such a protocol, and the interactions between 
  *>    Finally, it includes background material on how NSIS could support 
  *>    particular signaling applications. 
  *>     
  *>    It is expected that future versions of this document will distill 
  *>    these structural options into a concrete technical framework, and 
  *>    material on particular signaling applications and deployment 
  *>    scenarios will be moved into separate NSIS applicability statements. 
  *>     
  *> Conventions used in this document 
  *>     
  *>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
  *>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
  *>    document are to be interpreted as described in RFC-2119 [3]. 
  *>     

Since this document is not a formal specification, applicability words
are not appropriate, and indeed none are used.  Therefore the above
paragraph should be deleted.

  *> Table of Contents 
  *>     
...

  *>     
  *>  
  *> 1. Introduction 
  *> 

The following introductory paragraph is muddy in both terminology and
style; the summary in the Abstract is cleaner and clearer.  Suggest
starting from the Abstract and expanding it.

  *>    NSIS will work on signaling from an end point that follows a path 
  *>    through the net that is determined by layer 3 routing and is used to 
  *>    convey information to the devices the signals pass through - the 
  *>    signaling can, for example, install soft state in the devices it 
####                                        XXXX

(I believe that "convey information" and "install state" are semantically
equivalent.)

 *>    passes through. A signaling end point could be a device along the 
  *>    path, which signals for a data flow that passes through it. 
  *>    
  *>  
  *>    The intention is to allow for the NSIS protocol to be deployed in 
  *>    different parts of the Internet, for different needs, without 
  *>    requiring a complete end-to-end deployment.  
  *>     
  *>    There is no requirement that the per-flow information be QoS related. 

How about:
	The per-flow information might be related to QoS or to some other
	control function in routers and middleboxes along the path.

  *>    NSIS should only worry about how to do the signaling - what the 
  *>    signaling conveys should be opaque to NSIS. This document discusses 
  *>    'where' the signaling takes place, with some discussion on 'how' the 
  *>    signaling can be done. 
  *>     
  *> 1.1 Scope of the NSIS Framework 
...

  *>     
  *> 
  *>  
  *>  
  *> 2. Terminology 

Putting this termonology section early makes it tough for the reader
and certainly does not help her/him.  These terms are all introduced
and defined a bit later.  Capsule summaries of their definitions here,
besides being redundant, are without context and therefore hard to
follow.  I suggest moving this section to an Appendix for quick
reference, or at least to the end of Section 3.

  *> 
  *>    Classifier - an entity which selects packets based on their contents 
  *>    according to defined rules. 
  *>     
  *>    Interdomain traffic - Traffic that passes from one NSIS domain to 
  *>    another. 
  *>  
  *>    NSIS Domain (ND) - Administrative domain where an NSIS protocol 
  *>    signals for a resource or set of resources. 
  *>     
  *>    NSIS Entity (NE) - the function within a node which implements an 
  *>    NSIS protocol. In the case of path-coupled signaling, the NE will 
  *>    always be on the data path. 
  *>     
  *>    NSIS Forwarder (NF) - NSIS Entity between a NI and NR which may 
  *>    interact with local resource management function (RMF). It also 
  *>    propagates NSIS signaling further through the network. 
  *>     
  *>    NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a 
  *>    network resource. 
  *>     
  *>    NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and 
  *>    can optionally interact with applications as well. 
  *>     
  *>    NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS 
  *>    protocol component that supports a specific signaling application. 
  *>    See also section 3.1.3. 
  *>     
  *>    NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS 
  *>    protocol component that will support lower layer (signaling 
  *>    application independent) functions. See also section 3.1.3. 
  *>     
  *>    Path-coupled signaling - a mode of signaling where the signaling 
  *>    messages follow a path that is tied to the data messages. See also 
  *>    section 3.2.1. 
  *>     
  *>    Path-decoupled signaling - signaling with independent data and 
  *>    signaling paths. 
  *>     
  *>    Peer determination - the act of locating and/or selecting which NSIS 
  *>    peer to carry out signaling exchanges with for a specific data flow. 
  *>     
  *>    Peer relationship - signaling relationship between two adjacent NSIS 
  *>    entities (i.e. NEs with no other NEs between them). 

I found only 3 uses of "peer relationship" in the entire document.  Is it
useful to define it here?

  *>     
  *>    Receiver - the node in the network which is receiving the data 
  *>    packets in a flow. 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                  [Page 5] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>    Resource - something of value in a network infrastructure to which 
  *>    rules or policy criteria are first applied before access is granted. 
  *>    Examples of resources include the buffers in a router and bandwidth 
  *>    on an interface. 

This definition of "resource" needs more work.  It seems too QoS-specific.
Here is one suggestion, but I don't think this is the final word:

	Resource - something of value in a network infrastructure to
	which access is granted as the result of signaling. Examples of
	resources might include buffers in a router, bandwidth on an
	interface, and flow-specific access rights through a firewall.
	Signaled access to resources is generally restrained by policy
	control.

  *>     
  *>    Resource Management Function (RMF) - an abstract concept, 
  *>    representing the management of resources in a domain or a node. 

[note that RMF seems to not be an abstract concept in section 5.1]

  *>     
  *>    Sender - the node in the network which is sending the data packets in 
  *>    a flow. 
  *>     
  *>    Service Level Agreement (SLA) - a service contract between a customer 
  *>    and a service provider that specifies the forwarding service a 
  *>    customer should receive. 
  *>     
  *>    [NSIS] Signaling application - the purpose of the NSIS signaling: a 
  *>    service could be QoS management, firewall control, and so on. Totally 
  *>    distinct from any specific user application. 
  *>     
  *>    Traffic characteristic - a description of the temporal behavior or a 
  *>    description of the attributes of a given traffic flow or traffic 
  *>    aggregate. 
  *>     
  *>    Traffic flow - a stream of packets between two end-points that can be 
  *>    characterized in a certain way. 

Ambig. sentence.  Also, I don't think you want the "traffic" qualifier.
How about:

	Flow (or data flow) - a stream of packets, from sender to
	receiver, that is a distinguishable subset of the packet
	stream.  Each flow is distinguished by some flow identification
	(section 4.5.1).

  *>  
  *> 3. Overall Framework Structure 
  *> 
  *> 3.1 Basic Signaling Entities and Interfaces 
  *> 
  *> 3.1.1  NSIS Entities 
  *> 
  *>    The NSIS protocol is intended to be used as a signaling control plane 
  *>    for the variety of network resources required for data traffic across
  *>    the Internet. The most common NSIS signaling applications are QoS 
####                  Possible signaling applications include control of QoS

  *>    resources, firewalls and NATs resources, etc. The NSIS signaling 
  *>    itself does not depend on the signaling application it is used for 
  *>    but the information it carries does. This section discusses the basic 
  *>    signaling entities of the protocol as well as interfaces between 
  *>    them. 
  *>     
  *>    We can identify three different roles in the NSIS signaling for 
  *>    resources: initiator, forwarder and responder.  
  *>     
  *>    The NSIS Initiator (NI) is an entity that initiates NSIS signaling 
  *>    (request) for the network resource. The NSIS initiator can be 

(See my general comments about this definition... I have to struggle to
believe it.  It is NOT intuitive; consider RSVP v1.)

  *>    triggered by the different "sources" - user applications, an instance 
  *>    of NSIS Forwarder, other protocols, network management etc. - that 
  *>    need network resources for a data flow. For the purpose of the NSIS 
  *>    discussion all these sources can be called "applications" (note that 
  *>    this is entirely distinct from the specific term "signaling 
  *>    application"). The NSIS initiator can provide feedback information to 
  *>    the triggering application in respect to the requested network 
  *>    resources. The NSIS initiator uses NSIS signaling to interact with 
  *>    other NSIS entities (NFs and NRs). 
  *>     
  *>    The NSIS Forwarder (NF) is an entity that services NSIS resource 
  *>    requests from NSIS initiators and other NSIS forwarders. It may 
  *>    interact with local resource management function (RMF). How and if 
  *>    this interaction takes place depends on the deployed resource 
  *>    management mechanism and the specific role of the NF. The NSIS 
  *>    forwarder propagates NSIS signaling further through the network.  
  *>     
  *>    The NSIS Responder (NR) is an entity that terminates NSIS signaling 
  *>    and can optionally interact with local applications as well e.g. for 
  *>    the purpose of notification when network resources get allocated etc.  
  *>     
  *>    The signaling relationship between two NSIS entities (with no other 
  *>    NSIS entities between them) is called simply a 'peer relationship'. 

How about: Two NSIS entities that communicate directly are said to be
in a 'peer relationship'.

  *>    This concept might loosely be described as an 'NSIS hop'; however, 
  *>    there is no implication that it corresponds to a single IP hop. 
  *>    Either or both NEs might store some state information about the 
  *>    other, but there is no assumption that they establish a long-term 
  *>    signaling session between themselves. 
  *>     
  *>    Figure 1 depicts simplified interactions/interfaces between NI, NFs 
  *>    and NR as well as local applications and RMFs. Note that the NI and 
  *>    NR could also interact with an RMF; additionally, this could be 
  *>    modeled as co-location of NI&NF and NR&NF. This distinction should 
                              \
                                (and perhaps common implementation)
                               
  *>    have no impact on the operation of the protocol. Also, there is no 
  *>    bar on placing an NI or NR in the interior of the network, to 
  *>    initiate and terminate NSIS signaling independently of the ultimate 
  *>    endpoints of the end to end flow, and NI and NR do not have to talk 
  *>    via intervening NFs. An example of NSIS being used in this way is 
  *>    given in section 7.5. 
  *>      
  *>  
  *>    +-----------+                                        +-----------+ 
  *>    |Application|                                        |Application| 
  *>    +-----------+                                        +-----------+ 
  *>         ^                                                      ^ 
  *>         |                                                      | 
  *>         |  |____________|                      |____________|  | 
  *>         V  |            |                      |            |  V 
  *>        +----+          +----+              +----+          +----+ 
  *>        | NI |==========| NF |=====....=====| NF |==========| NR | 
  *>        +----+          +----+              +----+          +----+ 
  *>                          ^                    ^ 
  *>                          |                    | 
  *>                          V                    V 
  *>                        +----+              +----+ 
  *>                        |RMF |              | RMF| 
  *>                        +----+              +----+ 
  *>     

(See my general comment in other message.)

  *>     
  *>                    ===========  = NSIS signaling messages 
  *>     
  *>                    |_________|  = Scope of single NSIS 
  *>                    |         |    "peer relationship"        
  *>     
  *>                   Figure 1: Basic NI/NF/NR Relationships 

Much of this discussion is redundant with section 5.1, and section
7.2 adds a whole new dimension.  Wouldn't it be better/clearer to
simply omit the RMF from this particular early diagram??

  *>  
  *> 3.1.2  Placement of NSIS Entities 
  *> 
  *>    The NI, NF and NR definitions do not make any assumptions about 
  *>    placements of NSIS signaling entities in respect to the particular 
  *>    part of the network or data-forwarding path.  
  *>     
  *>    They can be located along the data path (hosts generating and 
  *>    receiving data flows, edge routers, intermediate routers etc.) but it 
  *>    may not be the only one desirable location. 

(This is OK if you make the following paragraph is part of the preceding
paragraph).

  *>     
  *>    In some cases it is desired to be able to initiate and/or terminate 
  *>    NSIS signaling not from the end host that generates/receives the data 
  *>    flow, but from the some other entities on the network that can be 
  *>    called NSIS signaling application proxies. There could be various 
  *>    reasons for this: signaling on behalf of the end hosts that are not 
  *>    enabled with NSIS, consolidation of the customer accounting 
  *>    (authentication, authorization) in respect to consumed application 
  *>    and transport resources, security considerations, limitation of the 
  *>    physical connection between host and network etc. The proxy can 
  *>    communicate the relevant information to the host in the application 
  *>    specific, maybe compressed, form.  

This proxy discussion is important, but it does raise design issues.
Shouldn't there be a separate subsection somewhere on proxies?
  
  *>  
  *>    Support for NSIS proxies affects the protocol in the following way: 
  *>     *) The protocol should accommodate signaling with the scope of a 
  *>    single NSIS peer relationship; the signaling could be propagated over 
  *>    multiple peer relationships all the way toward the destination (end-
  *>    to-end). 
  *>     *) In the particular case where the proxy is not on the data path, 
  *>    NSIS might have to be extended to allow separated data and signaling 
  *>    paths, although this analysis is not initially in scope.  
  *>     

I am not sure that it is best to treat proxies as a special case of
path-decoupled signaling, which is what you seem to be doing here.
The 2nd paragraph of sectionk 3.2.1, which treats proxies as a variant
of path-coupled signaling, seems more correct.

  *>    Further discussion of these issues is given in sections 3.2.1 and 
  *>    3.3.3. 
  *>     
  *>    As it can be seen from the usage cases presented in the NSIS 
  *>    requirements draft [2] the NSIS signaling procedures may depend on 
  *>    the part/type of the network where NSIS is used. In fact to satisfy 

What does "network type" mean?

  *>    sometimes-conflicting requirements in [2], different procedures and 
  *>    possibly different kinds of the NSIS protocol can be used on 

>>      different procedures and possibly different signaling applications
>>      can be used on

  *>    different parts/types of the network. Sections 3.2 and 7.5 provide 
  *>    more details on this topic. 
  *>     
  *> 3.1.3  NSIS Protocol Components 
  *> 
  *>    In order to achieve a modular solution for the NSIS requirements, it 
  *>    is proposed to structure what we refer to overall as 'the NSIS 
  *>    protocol' into 2 layers, similarly to the original proposal in [8]: 
  *>     *) a 'signaling transport' layer, responsible for moving signaling 
  *>    messages around, which should be independent of any particular 
  *>    signaling application; and 
  *>     *) a 'signaling application' layer, which contains functionality 
  *>    such as message formats and sequences, specific to a particular 
  *>    signaling application. 
  *>     
  *>    For the purpose of this document, we use the term 'NSIS Transport 
  *>    Layer Protocol' (NTLP) to refer to the component that will be used in 
  *>    the transport layer; it may or may not be based on the use of 
  *>    existing transport protocols. We also use the term 'NSIS Signaling 
  *>    Layer Protocol' (NSLP) to refer generically to any protocol component 
  *>    within the signaling application layer; in the end, there will be 
  *>    several NSLPs. These relationships are illustrated in Figure 2. 
  *>     
  *>     
  *>  
  *>                  ^                     +-----------------+ 
  *>                  |                     | NSIS Signaling  | 
  *>                  |                     | Layer Protocol  | 
  *>           NSIS   |    +----------------| for middleboxes | 
  *>        Signaling |    | NSIS Signaling |        +-----------------+ 
  *>          Layer   |    | Layer Protocol +--------| NSIS Signaling  | 
  *>                  |    |     for QoS     |       | Layer Protocol  | 
  *>                  |    |                 |       | for something   | 
  *>                  |    +-----------------+       |     else        | 
  *>                  V                              +-----------------+ 
  *>                       ============================================= 
  *>                  ^         +--------------------------------+ 
  *>                  |         | NSIS Transport Layer Protocol  | 
  *>           NSIS   |         |       ....................     | 
  *>        Transport |         |       .Standard transport.     | 
  *>          Layer   |         |       . protocol (maybe) .     | 
  *>                  |         |       ....................     | 
  *>                  V         +--------------------------------+ 
  *>     
  *>                     Figure 2: NSIS Protocol Components 
  *>  

If you (really) want to take a layerist view, then the lower layer should look
like:

                           ============================================= 
                      ^         +--------------------------------+ 
                      |         | NSIS Transport Layer Protocol  | 
                      |         |                                |
               NSIS   |         |................................| 
            Transport |         |        Standard transport      | 
              Layer   |         |         protocol (maybe)       | 
                      V         +--------------------------------+ 

  *>    The precise boundary between these layers is not defined at this 
  *>    stage; see section 3.3.5 for some initial discussion of this point. 
  *>     
  *> 3.2 Options for Modes of NSIS Operation 
  *> 
  *>    This section discusses several possible modes of NSIS operation. Each 
  *>    mode of NSIS operation is briefly introduced and where needed 
  *>    analyzed and compared with the alternatives. It is not assumed that 
  *>    NSIS will support all the mode variants described in these 
  *>    subsections; after the tradeoffs described here have been evaluated, 
  *>    some might be excluded from further consideration. 
  *>              
  *> 3.2.1  Path-Coupled and Path-Decoupled Signaling 

(I basically liked the discussion of this section)

  *> 
  *>    We can consider two basic paradigms for resource reservation 
  *>    signaling, which we refer to as "path-coupled" and "path-decoupled". 
  *>     
  *>    In the path-coupled case, signaling messages are routed only through 
  *>    nodes (NEs) that are in the data path. They do not have to reach all 
  *>    the nodes on the data path (for example, there could be proxies 
  *>    distinct from the sender and receiver as described in section 3.1.2, 
  *>    or intermediate signaling-unaware nodes); and between adjacent NEs, 
  *>    the route taken by signaling and data might diverge. The path-coupled 
  *>    case can be supported by various addressing styles, with messages 
  *>    either explicitly addressed to the neighbor on-path NE, or routed 
  *>    identically to the data packets and intercepted. These cases are 
  *>    considered in section 3.3.4. In the second case, some network 
  *>    configurations may split the signaling and data paths (see section 
  *>    5.2); this is considered an error case for path-coupled signaling. 
  *>     
  *>    In the path-decoupled case, signaling messages are routed to nodes 
  *>    (NEs) which are not assumed to be on the data path, but which are 
  *>    (presumably) aware of it. Signaling messages will always be directly 
  *>    addressed to the neighbor NE, and the NI/NR may have no relation at 
  *>    all with the ultimate data sender or receiver. 
  *>     
  *>    There are potentially significant differences in the way that the two 
  *>    signaling paradigms should be analyzed, for example in terms of 
  *>    scaling behavior, failure recovery, security properties, mechanism 
  *>    for NSIS peer determination, and so on. These differences might or 
  *>    might not cause changes in the way that the NSIS protocol operates. 
  *>     
  *>    The initial goal of NSIS and this framework is to concentrate mainly 
  *>    on the path-coupled case. 
  *>     
  *> 3.2.2  Inter-domain and Intra-domain Signaling 
  *> 

I don't like this section very much. It says too much and too little.
Maybe it needs to be merged with section 7.5?  Maybe it needs to be
grounded in a summary of RFC 2998?

  *>    Inter-domain NSIS signaling is where the NSIS signaling messages are 
  *>    originated in one NSIS domain and are terminated in another NSIS 
  *>    domain. 
  *>     
  *>    In the path-coupled case, inter-domain NSIS signaling can be used to 
  *>    signal NSIS information to the edge nodes of one or more NSIS 
  *>    domains. 
  *>     
  *>    In the path-decoupled case, inter-domain NSIS signaling can be used 
  *>    to signal NSIS information to entities that are not on the data path 
  *>    (i.e., "out-of-band" NFs), and additionally to signal from off-path 
  *>    entities to on-path edge nodes . 

I think the paragraph above is confused.  Perhaps you are introducing
"path-unrelated" signaling, which I claim is different from path-decoupled
signaling.  (See my overview message).

  *>     
  *>    NSIS inter-domain signaling has to fulfill several requirements, such 
  *>    as: 
  *>     *) Basic functionality, such as scalable, simple and fast signaling. 
'
Boooo!  "Scalable, simple, and fast" is devoid of content, and even if it
did have content, it would not hold just for inter-domain signaling.

  *>    Because different networks have different resource management 
  *>    characteristics, such as cost of bandwidth and performance, this 
  *>    basic functionality may differ from one NSIS domain to another. 
  *>     *) All other requirements specified in [2]. 

(Gratuitous.)

  *>     
  *>    Intra-domain NSIS signaling is where the NSIS signaling messages are 
  *>    originated, processed and terminated within the same NSIS domain. 
  *>    Note that these messages could be handled within a local instance of 
  *>    NSIS signaling; another possibility could be to piggyback them on 
  *>    inter-domain NSIS messages. 
  *>     
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 11] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>    Intra-domain signaling can be used to signal NSIS information to the 
  *>    edge nodes (i.e., routers located at the border of the NSIS domain) 
  *>    and to the interior nodes (i.e., routers located within the NSIS 
  *>    domain that are not edge nodes). 
  *>     
  *>    The NSIS intra-domain signaling approach has to fulfill fewer 
  *>    requirements than inter-domain signaling. These are: 
  *>     *) Basic functionality, such as scalable, simple and fast signaling. 

Booo again.

  *>    Due to the fact that different networks have different resource 
  *>    management characteristics, this basic functionality may differ from 
  *>    one NSIS domain to another. 
  *>     *) Provides the necessary functionality to interact between inter-
  *>    domain signaling and intra-domain signaling. 
  *>     
  *> 3.2.3  End-to-End, Edge-to-Edge, and End-to-Edge 
  *> 
  *>    End-to-end: When used end-to-end, the NSIS protocol is initiated by 
  *>    an end host and is terminated by another end host. In this context, 
  *>    NSIS can be applied as needed within all of the NSIS domains between 
  *>    the end hosts. In the end-to-end path, NSIS may be used both for 
  *>    intra-domain NSIS signaling, as well as for inter-domain signaling. 
  *>     
  *>    Edge-to-edge: In this scenario the NSIS protocol is initiated by an 
  *>    edge node of a NSIS domain and is terminated by another edge node of 
  *>    the same (or possibly different) NSIS domain. NSIS can be applied 
  *>    either within one single NSIS domain, which is denoted as edge-to-
  *>    edge in a single domain, or within a concatenated number of NSIS 
  *>    domains, which is denoted as edge-to-edge in a multi-domain. When an 
  *>    appropriate security trust relation exists between two or more 
  *>    concatenated NSIS domains, these concatenated NSIS domains are 
  *>    considered, in terms of NSIS, to be a single, larger NSIS domain. 
  *>     
  *>    End-to-edge: In this scenario the NSIS protocol is either initiated 
  *>    by an end host and is terminated by an edge node or is initiated by 
  *>    an edge node and is terminated by an end host. In the path-coupled 
  *>    case, the edge node may be a proxy that is located on a boundary node 
  *>    of a NSIS domain. In the path-decoupled case, the edge node may be a 
  *>    proxy that is located on an off-path node that controls, or is 
  *>    associated with, a NSIS domain. 
  *>     
  *> 3.2.4  Global and Local Operation 
  *> 
  *>    It is likely that the appropriate way to describe the resources NSIS 
  *>    is signaling for will vary from one part of the network to another. 
  *>    In particular, resource descriptions that are valid for inter-domain 
  *>    links will probably be different from those useful for intra-domain 
####          may be

  *>    operation (and the latter will differ from one NSIS domain to 
####                              may

  *>    another). 
  *>     
  *>    One way to describe this issue is to consider the resource 
  *>    description objects carried by NSIS (typically within the signaling 
  *>    application layer) as divided in globally-understood objects ("global 
  *>    objects") and locally-understood objects ("local objects"). The local 

The logical necessity of this distinction is unclear.
There may be a need for 'scope' of resource description objects, but it
isn't clear that 1 bit (local/global) is fundamental or sufficient.

  *>    objects are only applicable for intra-domain signaling, while the 
  *>    global objects are mainly used in inter-domain signaling. Note that 
  *>    such local objects are still part of the NSIS protocol, unlike opaque 

?? Huh??

  *>    data which would be invisible to the protocol; local objects can be 
  *>    inserted, used and removed by one single domain. 
  *>     
  *>    The purpose of this division is to provide additional flexibility in 
  *>    defining the objects carried by the NSIS protocol such that only 
  *>    those objects that are applicable in a particular setting are used. 
  *>    An example approach for reflecting the distinction in the signaling 
  *>    is that local objects could be put into separate local messages that 
  *>    are initiated and terminated within one single NSIS domain and/or 
  *>    they could be "stacked" within the NSIS messages that are used for 
  *>    inter-domain signaling. These possibilities will be considered 
  *>    further during the protocol design activity. 
  *>     
  *> 3.2.5  Multicast versus Unicast 
  *> 
  *>    Multicast support, compared to unicast support, would introduce a 
  *>    level of complexity into the NSIS protocol mainly related to: 
  *>     *) complex state maintenance to support dynamic membership changes 
  *>    in the multicast groups, such as reservation state merging and 
  *>    maintenance. 
  *>     *) a state per flow has to be maintained that is used during 
  *>    backward routing. 
  *>     
  *> 3.2.6  Sender versus Receiver Initiated Signaling 
  *> 
  *>    A sender-initiated approach is when the sender of the data flow 
  *>    initiates and maintains the resource reservation used for that flow. 
  *>    In a receiver-initiated approach the receiver of the data flow 
  *>    initiates and maintains the resource reservation used for the data 
  *>    flow. 
  *>     

This is a slippery dichotomy.  You have slipped into saying "reservation",
which is QoS-specific.  Does the distinction hold for other signaling
applications?

  *>    In the path-coupled case, and in the absence of NSIS proxies, the 
  *>    following relationships apply: 
  *>     *) in the sender initiated case, the sender of the data is the NSIS 
  *>    Initiator, while the receiver of the data is the NSIS Responder; 
  *>     *) in the receiver initiated case, the receiver of the data is the 
  *>    NSIS Initiator, while the sender of the data is the NSIS Responder. 

You have fallen into the Pit of Confusion here!  The last statement is
simply not true, as the RSVP example shows.  Each of sender and receiver
is both NI and NR, in the RSVP case.

  *>    In the path-decoupled case, the mapping is not necessarily clear cut 
  *>    (for example, if the NI and NR are not located at the end systems 
  *>    themselves). 
  *>     
  *>    The main differences between the sender-initiated and receiver-
  *>    initiated approaches are the following: 
  *>     *) Compared with the receiver-initiated approach, a sender using a 
  *>    sender-initiated approach can be informed faster when the reservation 
  *>    request is rejected. In other words, when using a sender-initiated 
  *>    approach, the reservation request response time can be shorter in the 
  *>    case of an unsuccessful reservation than with a receiver-initiated 
  *>    approach. 

Yes, and a receiver using the receiver-initiated approach can be
informed faster.  What is your point?

  *>     *) In a receiver-initiated approach, the signaling messages 
  *>    traveling from the receiver to the sender must be backward routed 
  *>    such that they follow exactly the same path as was followed by the 
  *>    signaling messages belonging to the same flow traveling from the 
  *>    sender to the receiver. This implies that a backward routing state 
  *>    per flow must be maintained. When using a sender-initiated approach, 
  *>    provided acknowledgements and notifications can be securely delivered 
  *>    to the sending node, backward routing is not necessary, and nodes do 
  *>    not have to maintain backward routing states. 

  *>     *) In a sender-initiated approach, a mobile node can initiate a 
  *>    reservation for its outgoing flows as soon as it has moved to another 
  *>    roaming subnetwork. In a receiver-initiated approach, a mobile node 
  *>    has to inform the receiver about its handover procedure, thus 
  *>    allowing the receiver to initiate a reservation for these flows. 

This again seems to be half of a dual argument, since mobile nodes both send
and receive.

  *>     *) Where the signaling is looking for the last (nearest to receiver) 
  *>    NE on the data path, receiver oriented signaling is most efficient; 
  *>    sender orientation would be possible, but take more messages. 

The preceding discussion was one-sided.  It should mention the overwhelming
scaling advantages of receiver orentation for multicast reservations.

  *>     
  *> 3.2.7  Uni-Directional and Bi-Directional Reservations 
  *> 

How about: "Reservations" -> "Resource Requests"

  *>    It is possible that a resource will only be required for one 
  *>    direction of traffic, for example for a media stream with no feedback 
  *>    channel. Reservations for both directions of traffic may be required 
  *>    for other applications, for example a voice call. Therefore, the NSIS 
  *>    signaling protocol must allow for both uni- and bi-directional 
  *>    resource reservations. 

I would claim that the sentence above is tautologous; a signaling
protocol cannot help itself from supporting bi-directional
reservations.  You just use the protocol in both directions, as the
following sentence says.

  *>    The most basic method for bi-directional reservations is based on 
  *>    combining two uni-directional reservations. This allows that the 
  *>    signaling messages for one direction of the bi-directional 
  *>    reservation are able to follow a different path from messages 
  *>    traveling in the opposite direction, which is necessary for path-
  *>    coupled signaling in the presence of asymmetric routing. (Other more 
  *>    integrated approaches may be possible in constrained network 
  *>    topologies where parts of the route are symmetric.) The bi-
  *>    directional reservations can, for example, be used to make the NSIS 
  *>    signaling procedure required after a handover procedure more 
  *>    efficient. 
  *>  

How about:
	A resource will only be required for one direction of traffic,
	for example QoS for a media stream with no feedback channel.
	On the other hand, some applications will have bi-directional
	resource requirements; an example is QoS for a voice call.
	Bi-directional resource requests can simply use a separate
	instance of the same signaling mechanism in each direction.
	Note that the paths in the two directions may differ due to
	assymmetric routing.

	In constrained topologies where parts of the route are
	symmetric, it may be possible to use a more unified approach to
	bi-directional signaling, e.g., carrying the two signaling
	directions in common messages.  This optimization might be used
	to make mobile QoS signaling more efficient.  

  *>   
  *>  
  *> 3.3 Basic Assumptions and Conceptual Issues 
  *> 
  *> 3.3.1  Basic Assumptions 
  *> 
  *>    The following assumptions have been made during prior NSIS 
  *>    requirements work and initial framework discussions. They are 
  *>    summarized here for completeness. The subsequent subsections describe 
  *>    more generic conceptual assumptions and issues. Note that a complete 
  *>    overview of current open issues is contained in section 8. 
  *>  
  *>     *) The solution developed by NSIS must be sufficiently flexible and 
  *>    modular that it can be efficiently deployed and used with 
  *>    functionality appropriate to the part/type of the network. (Sections 
  *>    3.2.2 and 3.2.3.) 
  *>     
  *>     *) The protocol developed by the NSIS working group will be path-
  *>    coupled. Considerations related to a potential path-decoupled 
  *>    solution are part of this framework, because they are also needed in 
  *>    order to co-exist with existing solutions; however, the NSIS working 
  *>    group currently has no plans to develop path-decoupled signaling 
  *>    protocol. (Section 3.2.1.) 
  *>     
  *>     *) End-to-end message routing will be achieved by each NE 
  *>    determining the next appropriate NSIS peer, based on the flow in 
  *>    question and information within the NTLP layer, not requiring any 
  *>    node or the upper layers to acquire end-to-end topology information. 

This seems like a statement about detailed design that may in fact
be wrong for some signaling applications.

  *>    (Section 3.2.4.) 

Sectionk 3.2.4?? I don't see the relevance.

  *>     
  *>     *) Multicast support introduces a level of complexity into the NSIS 
  *>    protocol that is not needed in support of unicast applications. 
  *>    Therefore, a working assumption is be that the NSIS protocol should 
  *>    be optimized for unicast. (Section 3.2.5.) 
  *>     
  *>     *) The NSIS protocol can be used for setup of both uni-directional 
  *>    and bi-directional reservations. (Section 3.2.7.) 
  *>  
  *> 3.3.2  NI, NF, NR functionality 
  *> 
  *>    The basic functions that can be fulfilled by an NSIS entity are 
  *>    request, accept, notify, modify and release of a reservation. At this 

A "reservation"? Sounds like an assumption of QoS signaling.

There was an extended debate in the RSVP WG about whether or
not an Accept is required, and in the end only a very weak form of it
was included.

Need definitions of these terms (which are redundantly supplied in
section 4.2; these should be combined.)

  *>    point, it is not clear which responsibilities can be assumed by each 
  *>    of the NSIS entities. More in particular, it is not clear whether: 
  *>     *) an NF can request, modify or release a reservation. If it cannot, 
  *>    it needs to notify the NI in order to perform these functions. 
####	it would need to ...

  *>     *) an NR can modify and release a reservation. Even if the NR can 
  *>    reject or accept the reservation with modification, it might still be 
  *>    required to notify the NI to signal the release or modification. 
  *>     
  *>  
  *> 3.3.3  NI, NF, NR relationship 
  *> 
  *>    An important open issue is related to the way in which NSIS entities 
  *>    maintain relations between each other. These relations could be 
  *>    purely local, where an NSIS entity only maintains relations with its 
  *>    direct neighbors (peers). In that case, messages will be sent to and 
  *>    accepted from these neighbors only. Alternatively, the relations 
  *>    between NSIS entities could have a more global scope. 
  *>     

I like this paragraph, because you slipped into using the terms I
favor, "neighbors"  ;-).  More seriously, the neighbor/peer distinction
surfaces here. How about:

	NSIS entities that communicate with each other are peers.
	Peering of entities might be limited to neighbor nodes, so that
	entities can only communicate hop/hop along the path.
	Alternatively, the framework might allow remote peering, i.e.,
	peering with nodes that are not neighbors.

  *>    The type of NSIS peering relations may have an impact on the 
  *>    complexity involved with protocol security. In case of inter-domain 
  *>    signaling, the security relations are likely to be built between 
  *>    neighboring NSIS entities only for scalability reasons. In that case, 
  *>    each NSIS entity will establish and maintain a security relation with 
  *>    each of its peers and accept only messages from these peers. 
  *>     
  *>    Conversely, there may exist larger domains of NSIS entities that have 
  *>    a trust relationship (trusted domains). This may be the case for 
  *>    intra-domain signaling. In this case, an NE may accept messages from 
  *>    all other NSIS entities in the domain. Both alternatives need not be 
  *>    mutually exclusive. It is conceivable that different instances of the 
  *>    NSIS protocol (or different NSIS protocols) use the NSIS security 
  *>    model to a larger or lesser extent, provided that overall security is 
  *>    not impacted. An analysis of NSIS threats is available from [5]. 
  *>     
  *>    The NSIS peering relations may also have an impact on the required 
  *>    amount of state at each NSIS entity. When direct interaction with 
  *>    remote NSIS peers is not allowed, it may be required to keep track of 
  *>    the path that an NSIS message has followed through the network. This 
  *>    can be achieved by keeping per-flow state at the NSIS entities or by 
  *>    maintaining a record route object in the NSIS messages. 
  *>     
  *>    An initial working assumption is that the NTLP will operate 
  *>    'locally', that is, just over the scope of a single peer 
  *>    relationship. End-to-end operation is built up by simply 
  *>    concatenating these relationships. Any non-local operation (if any) 
  *>    will take place only in particular NSLPs. 
  *>     
  *> 3.3.4  NSIS Addressing 
  *> 
  *>    The are potentially two ways to establish a signaling connection by 

"connection"?  Overloaded word...

  *>    means of the NSIS protocol. On the one hand, the NSIS message could 
  *>    be addressed to a neighboring NSIS entity (NE) that is known to be 
  *>    closer to the destination NE. On the other hand, the NSIS message 
  *>    could be addressed to the destination directly, and intercepted by an 
  *>    intervening NE. We denote the latter approach as end-to-end 
  *>    addressing and the former as peer-peer addressing.    
  *>  
  *>    With peer-peer addressing, an NE will determine the address of the 
  *>    next NE based on the payload of the NSIS message (and potentially 
  *>    also on the previous NE). This requires the address of the 
  *>    destination NE to be derivable from information present in the 
  *>    payload. This can be achieved through the availability of a local 
  *>    routing table or through participation in the routing protocol. Peer-
  *>    peer addressing inherently supports tunneling of NSIS signaling 
  *>    messages between NEs, and is equally applicable to the path-coupled 
  *>    and path-decoupled cases. 
  *>     
  *>    In case of end-to-end addressing, the NSIS message will be sent with 
  *>    the address of the NR, which then necessarily needs to be on the data 
  *>    path. This requires (some of) the data-path entities to be upgraded 
  *>    (NSIS-aware) in order to be able to intercept the NSIS messages. The 
  *>    routing of the NSIS signaling should follow exactly the same path as 
  *>    the data flow for which the reservation is requested. 
  *>     
  *> 3.3.5  NSIS Layer Boundaries 
  *> 
  *>    The detailed boundary between the NTLP and NSLPs is an area for 
  *>    (considerable) further analysis. In particular, it is not clear how 
  *>    the key issues described earlier (such as sender/receiver 
  *>    orientation) are allocated to the different layers. However, some 
  *>    initial assumptions have been made about the functionality in 
  *>    different layers. 
  *>     
  *>    *) It is assumed that some flow description information is part of 
####                               flow identification is part of

  *>    the NTLP (see section 4.3.1 and 4.5.1). This might be needed by 
  *>    signaling application unaware entities located at address boundaries. 
  *>    It is not clear to which level of complexity the flow description 
  *>    needs to be available at this level. 

Note that my 2level model does NOT make this assumption.  CSTP (your
NTLP) is not aware of the flow indentification for a signaling packet;
that is up to the particular ULSP.  I would suggest that my
modularity is better, since the choice of flow indentification is
probably specific to different classes of signaling applications.
Making the CSTP aware of the FId will require that you identify the
most general possible FId early on, which seems like a bad idea.
(On the other hand, you may be able to show that my design in fact
has some serious drawback, so that FId info is essential in the
lower level.)

  *>     *) It is not assumed that the operation of an NSLP is totally 
  *>    independent of the NTLP; for example, the appropriate interpretation 
  *>    of an NSLP message might depend on the local status of the NTLP. 
  *>     

I disagree with this.  How about:

	*) It is highly desirable to be able to create NSLP signaling
	applications that are independent of the internal operation of
	the NSLP.  This modularity will allow independent evolution
	of the two protocol layers.

  *> 3.3.6  NSIS Acknowledgement and Notification Semantics 
  *> 
  *>    The semantics of the acknowledgement and notification messages are of 
  *>    particular importance. An NE sending a message can assume 
  *>    responsibility for the entire downstream chain of NEs, indicating for 
  *>    instance the availability of reserved resources for the entire 
  *>    downstream path. Alternatively, the message could have a more local 
  *>    meaning, indicating for instance that a certain failure or 
  *>    degradation occurred at a particular NSIS entity. 
  *>  
  *> 
  *> 
  *>   
  *>  
  *> 4. Protocol Components 
  *> 
  *> 4.1 Lower Layer Interfaces 
  *> 
  *>    Within a signaling entity, NSIS interacts with the 'lower layers' of 

Within an NE? Or within a node that supports an NE? (Terminolgy alarm)

  *>    the protocol stack for two nearly independent purposes: sending and 
  *>    receiving signaling messages; and configuring the operation of the 
  *>    lower layers themselves. 
  *>     
  *>    For sending and receiving messages, this framework places the lower 
  *>    boundary of the NTLP at the IP layer. (It is possible that NSIS could 
  *>    use a standard transport protocol above the IP layer to provide some 
  *>    of its functionality; this is discussed in section 4.3.1.) The 
  *>    interface with the lower layers is therefore very simple: 
  *>     *) The NTLP sends raw IP packets 
  *>     *) The NTLP receives raw IP packets. In the case of peer-peer 
  *>    addressing, they have been addressed directly to it. In the case of 
  *>    end-to-end addressing, this will be by intercepting packets that have 
  *>    been marked in some special way (by special protocol number or by 
  *>    some option interpreted within the IP layer, such as the Router Alert 
  *>    option [6] and [7].)  
  *>     
  *>    For correct message routing, the NTLP needs to have some information 
  *>    about the link and IP layer configuration of the local networking 
  *>    stack. For example, it needs to know: 

You probably need route change notification upcalls for local repair,
and you may need route pinning.

  *>     *) [in general] how to select the outgoing interface for a signaling 
  *>    message, in case this needs to match the interface that will be used 
  *>    by the corresponding flow. This might be as simple as just allowing 
  *>    the IP layer to handle the message using its own routing table. 
  *>     *) [in the case of IPv6] what address scopes are associated with the 
  *>    interfaces that messages are sent and received on (to interpret 
  *>    scoped addresses in flow identification, if these are to be allowed). 
  *>     
  *>    The way in which the lower layers are actually configured to handle 
  *>    the flow depends on the particular NSIS signaling application; for 
  *>    example, if NSIS is being used for QoS signaling, this might involve 
  *>    configuration of traffic classification and conditioning parameters, 
  *>    for example local packet queues, type of filters, type of scheduling, 
  *>    and so on. However, none of this is directly related to the NTLP or 
  *>    indeed any NSLP; therefore, this interaction is handled indirectly 
  *>    via a resource management function, as described in section 5.1. 
  *>     
  *> 4.2 Upper Layer Services 
  *> 
  *>    The combination of the NTLP and an NSLP provides a signaling service, 
  *>    appropriate for a particular signaling application. We can describe 
  *>    such a signaling service as an abstract set of capabilities, provided 
  *>    at a service interface, defined from three perspectives: 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 18] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>     *) What basic control primitives are available at the interface; 
  *>     *) What information is exchanged within these primitives; 
  *>     *) What assumptions are made about operations carried out above the 
  *>    interface.  
  *>     
  *>    The set of control primitives required is quite small. 
  *>    At the initiating (NI) end: 
  *>     *) Signaling application requests signaling for a new resource; 
  *>     *) Signaling application requests modification or removal of an 
  *>    existing resource. 
  *>     *) Signaling application receives progress indications (minimally, 
  *>    success or failure). 
  *>    At the responding (NR) end: 
  *>     *) Notification to signaling application that a resource has been 
  *>    set up. 
  *>    At either end: 
  *>     *) Notification to signaling application that something has changed 
  *>    about the available resource and other error conditions. 
  *>     

The list above should be combined with section 3.3.2.

  *>    This description is in terms of a 'hard state' interface, without 

No.  How about:

	These control primitives are independent of the issue of whether
	the control information [state] must be removed with an explicit
	release request (hard state) or whether it will time out in the
	absence of refresh messages (soft state).  The latter will ensure
	that state is removed despite possible failure of signaling applications.

  *>    explicit refresh messages between the signaling application and NSIS, 
  *>    although this is an implementation issue. In any case, 
  *>    implementations will need to be able to detect conditions when 
  *>    instances of signaling applications fail without issuing explicit 
  *>    resource removal requests. 
  *>     
  *>    The information in the control primitives consists essentially of two 
  *>    parts. The first is the definition of the data flow for which the 
  *>    resource is being signaled. The format (e.g. socket id or packet 
  *>    fields or whatever) is an implementation issue; it has to be 
  *>    interpreted into a 'wire format' (as in section 4.5). Since NSIS 
  *>    could support both sender and receiver initiation, the flow 
  *>    definition must also state whether it is incoming or outgoing over a 
  *>    particular interface (this can be inferred when the initiator is 
  *>    colocated with the flow endpoint). The second part of the information 
  *>    exchanged is the service definition (e.g. QoS description in the case 
  *>    of a QoS request). This will be opaque at least to the NTLP, which 
  *>    only knows the specific NSLP being used. 
  *>     
  *>    We have a basic design goal not to duplicate functionality that is 
  *>    already present in (or most naturally part of) existing signaling 
  *>    protocols which could be used by the upper layers. Therefore NSIS 
  *>    (implicitly) assumes that certain procedures are carried out 
  *>    'externally'. The main aspects of this are: 
  *>     *) Negotiation of service configuration (e.g. discovering what 
  *>    services are available to be requested); 
  *>     *) Agreement to use NSIS for signaling, and coordination of which 
  *>    end will be the initiator. 

This is good.

  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 19] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>     
  *>    In addition, as well as NSIS (presumably the NTLP) providing a 
  *>    'native' capability to determine the peer to carry out signaling 
  *>    with, it is possible that this information could be provided from 
  *>    some external source (which might be helpful in some access 
  *>    scenarios, or in the path-decoupled case). See also the security 
  *>    discussion in section 6. 
  *>     
  *>    Actually providing these functions might require enhancements to 
  *>    these other protocols. These are still to be identified. 
  *>  
  *> 4.3 Protocol Structure 
  *> 
  *> 4.3.1  Internal Layering 
  *> 
  *>    We can model NSIS in two layers, as shown in Figure 3. This is 
  *>    initially just a way of grouping associated functionality, and does 
  *>    not mean that all these layers could necessarily operate or even be 
  *>    implemented independently. 

I'm not sure I agree with the last sentence.

  *>     
  *>                     .................................. 
  *>                     .     Signaling Application      . 
  *>                     .        (section 4.2)           . 
  *>                     .                                . 
  *>                     +--------------------------------+ 
  *>                     | NSIS Signaling Layer Protocol  | 
  *>                     |  (for some specific signaling  | 
  *>                     |          application)          | 
  *>                     |                                | 
  *>                     +--------------------------------+ 
  *>                     | NSIS Transport Layer Protocol  | 
  *>                     |      ....................      | 
  *>                     |      .Standard transport.      | 
  *>                     |      . protocol (maybe) .      | 
  *>                     |      ....................      | 
  *>                     +--------------------------------+ 
  *>                     .     Interface to IP layer      . 
  *>                     .         (section 4.1)          . 
  *>                     .                                . 
  *>                     .................................. 
  *>     
  *>                       Figure 3: NSIS Layer Structure 

This diagram seems redundant with Figure 2.  See also my comment there.

  *>     
  *>    The lower layer interface (to IP) has been described in section 4.1. 
  *>    The support of the signaling application is as described in section 
  *>    4.2. The degree of independence between the NTLP and NSLP is unclear 
  *>    and might depend on the particular signaling application. To make the 
  *>    NTLP independent of the signaling application, we must allow that 
  *>    NSLPs could be explicitly dependent on the layer below. This is 

?? Huh?? I don't understand this.

  *>    similar to the ALSP/CSTP coupling described in [8]. 
  *>     
  *>    The distinction between the NTLP and any 'Standard Transport 
  *>    Protocol' is not functionally clear cut, but one of convenience. In 
  *>    outline: 
  *>     *) The 'standard' protocol could provide (at most) functionality 
  *>    which might be available from existing protocols, such as SCTP [9] or 
  *>    IPSec [10]. An extreme case could be the binding update messages of 
  *>    mobility signaling (section 5.3.4). 
  *>     *) The NTLP provides (at least) functionality which is somehow 
  *>    specific to path-coupled signaling. 
  *>     
  *>    Functionality reasonable to re-use from existing protocols might 
  *>    include reliability and re-ordering protection, dead peer detection 
  *>    (keepalive), multihoming support, payload multiplexing 

(BTW, strictly, existing transport protocols (TCP, UDP) don't provide
keep-alives.  The NTLP can program keep-alives, however.)

  *>    (piggybacking), and security services, such as establishment of 
  *>    security contexts and carrying out key exchange. 
  *>     
  *>    Functionality which would probably have to be in the NTLP would 
  *>    include flow and reservation identification, some error handling, 
>>              ...................................
(See my earlier comment about CSTP)

  *>    demultiplexing between different NSLPs, as well as possibly the basic 
  *>    NSIS messages. More details on the messages are in section 4.3.2 and 
  *>    the identifier aspects in section 4.5. 
  *>     
  *>    The choice of using functionality from an existing protocol or re-
  *>    specifying it as part of the NTLP is for further analysis. It 
  *>    probably depends on the function in question, and in the end might be 
  *>    left flexible to allow optimization to local circumstances. (For 
  *>    example, Diameter allows the use of IPSec for security services, but 
  *>    also includes its own CMS application as an alternative.) Whichever 
  *>    approach is taken, the combination of NTLP and supporting transport 
  *>    protocol must provide a uniform protocol capability to the NSLPs 
  *>    which support the actual signaling applications. 
  *>  
  *> 4.3.2  Protocol Messages 
  *> 
  *>    The NSIS protocols will include a set of messages to carry out 
  *>    particular operations along the signaling path. Initial work for RSVP 
  *>    concentrated on the particular case of QoS signaling, although the 
  *>    implication of the analysis in [8] is that this message set 
  *>    generalizes to a wide variety of signaling applications and so we use 
  *>    it as a starting point. (A very similar set of messages was generated 
  *>    in [11].) However, in principle, the necessary basic messages could 
  *>    depend on the signaling application that NSIS is being used for, 
  *>    which means that we are not specific here about whether these 
  *>    messages are visible within the NTLP or only NSLP.    
  *>  
  *>    Note that the 'direction' column in the table below only indicates 
  *>    the 'orientation' of the message. The messages can be originated and 
  *>    absorbed at NF nodes as well as the NI or NR; an example might be NFs 
  *>    at the edge of a domain exchanging NSIS messages to set up resources 
  *>    for a flow across a it. 

I question that example; perhaps it would be more consistent with the
model to consider that the NFs at the edge are then acting as NIs.

  *>     
  *>    Note the working assumption that responder as well as the initiator 
  *>    can release a reservation (comparable to rejecting it in the first 
  *>    place). It is left open if the responder can modify a reservation, 
  *>    during or after setup. This seems mainly a matter of assumptions 
  *>    about authorization, and the possibilities might depend on resource 
  *>    type specifics. 
  *>     
  *>    +-------+---------+---------------------------------------------+ 
  *>    | Name  |Direction|                  Semantics                  | 
  *>    +-------+---------+---------------------------------------------+ 
  *>    |Request| I-->R   |     Create a new reservation for a flow     | 
  *>    +-------+---------+---------------------------------------------+ 
  *>    |Modify | I-->R   |        Modify an existing reservation       | 
  *>    |       |(&R-->I?)|                                             | 
  *>    +-------+---------+---------------------------------------------+ 
  *>    |Release| I-->R & |  Delete (tear down) an existing reservation | 
  *>    |       |  R-->I  |                                             | 
  *>    +-------+---------+---------------------------------------------+ 
  *>    |Accept/| R-->I   |  Confirm (possibly modified?) or reject a   | 
  *>    | Reject|         |             reservation request             | 
  *>    +-------+---------+---------------------------------------------+ 
  *>    |Notify | I-->R & |     Report an event detected within the     | 
  *>    |       |  R-->I  |  network (e.g. congestion condition or end  | 
  *>    |       |         |                of condition)                |

I worry about a naive introduction of congestion mechanism here.  How will it
interact with Internet congestion control?  Internet congestion is
a large and deep topic.

  *>    +-------+---------+---------------------------------------------+ 
  *>    |Refresh| I-->R   |      State management (see section 4.4)     | 
  *>    +-------+---------+---------------------------------------------+ 
  *>     
  *>    The table also explicitly includes a refresh message. This does 
  *>    nothing to a reservation except extend its lifetime, and is one 
  *>    possible state management mechanism for NSIS. This is considered in 
  *>    more detail in section 4.4. 
  *>     
  *> 4.4 State Management 
  *> 
  *>    The prime purpose of NSIS is to manage state information along the 
  *>    path taken by a data flow. There two critical issues to be considered 
  *>    in building a robust protocol to handle this problem: 
  *>     *) The protocol must be scalable. It should minimize the state 
  *>    storage demands that it makes on intermediate nodes; in particular, 
  *>    storage of state per 'micro' flow is likely to be impossible except 
  *>    at the very edge of the network.

How about:
	For example, storage of resource state for every micro-flow may
	be infeasible in core networks but feasible at the network edges.

  *>     *) The protocol must be robust against failure and other conditions, 
  *>    which imply that the stored state has to be moved or removed. 
  *>     
  *>    The total amount of state that has to be stored depends both on NSIS 
  *>    and on the specific signaling application in use. The signaling 
  *>    application might require per flow or lower granularity state; 
####                              per micro-flow or ...

  *>    examples of each for the case of QoS would be IntServ or RMD (per 
  *>    'class' state) respectively. The NSIS protocol should not overburden 
  *>    an application that was otherwise lightweight in state requirement. 

WHAT does that last sentence mean??  (Suggest delete it.)

  *>    However, depending on design details, it might require storage of 
  *>    per-flow state including reverse path peer addressing, simply for 
  *>    sending NSIS messages themselves. 
  *>     
  *>    There are several robustness problems, which roughly align with the 
  *>    'layers' of the NSIS protocols of Figure 3, that can be handled by 
  *>    the soft state principle. (Independence of these layers therefore 
  *>    implies the danger of duplication of functionality.) This relies on 

What does the sentence in parentheses mean?

  *>    periodic refresh of the state information with the current context, 
  *>    relying on invalid state being timed out. Soft state can be used 
  *>    either as the primary mechanism to handle the problem, or sometimes 
  *>    as a backup to some other approach. 
  *>     

You can be more explicit than "some other approach".

  *>     *) At the lowest level, soft state can be used to detect dead NSIS 
  *>    peers - loss of several periodic messages implies termination of the 
  *>    signaling. (The same inference can be made e.g. if failure is 
  *>    detected at the link layer.) The assumption is then that the 
  *>    corresponding reservation should be automatically deleted, and the 
  *>    deletion propagated along the remainder of the path. 
  *>     
  *>     *) At the next level, in the event of a routing change (for example 
  *>    caused by network changes or end host mobility), reservation state 
  *>    should be removed from the old path and added to the new one. This 
  *>    will be handled automatically by periodic messaging, provided that 
  *>    the entities on the new path accept a Refresh message to install a 
  *>    new reservation. (A partial alternative is to have a routing-aware 
  *>    NSIS implementation, if the route change takes place at an NSIS-aware 
  *>    node.) 

	How about:
		To provide immediate response to a routing change, it is
		desirable to have the signaling protocol notified of
		routing changes so it can do local repair.

  *>     
  *>     *) At the highest level, a particular signaling application might 
  *>    have timing limits associated with a particular reservation (e.g. 
  *>    credit limited network access). Periodic re-authorized requests can 
  *>    be used as part of the time control. 
  *>     
  *>    All of these can be handled with a single soft state mechanism, 
  *>    although it may be hard to choose a single refresh interval and 
  *>    message loss threshold appropriate for all of them. Even where 
  *>    alternative approaches are possible, for example using knowledge of 
  *>    the fact that a routing change has occurred to trigger an explicit 
  *>    release message, it seems that a soft state mechanism is always 
  *>    necessary as a backup. 
  *>     

Even such a soft-state booster as myself would not claim "necessary";
how about "desirable"?

  *> 4.5 Identity Elements 
  *> 
  *>    NSIS will carry certain identifiers within the NTLP. The most 
  *>    significant identifier needs seem to be the following. 
  *>     
  *> 4.5.1  Flow Identification 
  *> 
  *>    The flow identification is a method of identifying a flow in a unique 
  *>    way. All packets and/or messages that are associated with the same 
  *>    flow will be identified by the same flow identifier. In principle, it 
####                                        flow identification. For example, it

  *>    could be a combination of the following information (note that this 
  *>    is not an exclusive list of information that could be used for flow 
  *>    identification): 
  *>     *) source IP address; 
  *>     *) destination IP address; 
  *>     *) protocol identifier and higher layer (port) addressing; 
  *>     *) flow label (typical for IPv6); 
  *>     *) SPI field for IPSec encapsulated traffic; 
  *>     *) DSCP/TOS field 
  *>     
  *>    We've assumed here that the flow identification is not hidden within 
  *>    the NSLP, but is explicitly part of the NTLP. The justification for 
  *>    this is that it might be valuable to be able to do NSIS processing 
  *>    even at a node which was unaware of the specific signaling 
  *>    application; this would be a case of an NSIS forwarder with no 
  *>    interface to any resource management function. An example scenario 
  *>    would be NSIS messages passing through an addressing boundary where 
  *>    the flow identification had to be re-written. 
  *>     

This is an interesting example, but I still think that such rewriting
would want to be done at the ULSP level.  You have to make some
strong assumptions here (which are not discussed anywhere in your
document): that the SAPU is encoded in such a way that an NE that
is unaware of its detailed contents can still determine what fields
contain addresses that need to be translated.  Or else, you HAVE
to have an instance of a particular signaling application to do
the rewriting in any node.

  *>    The very flexibility possible in flow classification is a possible 
  *>    source of difficulties: when wildcards or ranges are included, it is 
  *>    probably unreasonable to assume a standard classification capability 
  *>    in routers; on the other hand, negotiating this capability would be a 
  *>    significant protocol complexity. 
  *>     
  *> 4.5.2  Reservation Identification 
  *> 
  *>    There are several circumstances where it is important to be able to 
  *>    refer to a reservation independently of whatever other information is 
####                                            its flow identification.XXXXX

  *>    associated with it. The prime example is a mobility-induced address 
####    XXXXXXXXXXXXXXXXXXX

  *>    change (handover) which required the flow identifier associated with 
####                                         flow identification

  *>    a reservation to be rewritten without installing a totally new 
  *>    reservation (see section 5.3.1 for some security and scoping 
  *>    implications of this use). The same capability could also be used to 
  *>    simplify refresh or release messages in some circumstances, and might 
  *>    be useful within the protocol to resolve reservation collisions 
  *>    (where both sender and receiver initiate for the same flow). 

I have yet to be convinced that it is actually "important".  The last
reason seems weak; a competant protocol design would take account
of such collision if it is a possibility, and using the flow
identification.

  *>     
  *>    A reservation identifier performs these roles. It is open how the 
  *>    reservation identifier space should be defined and managed, and what 
  *>    the scope of the identifier should be (only peer-peer, or end-end, 
  *>    when interpreted in conjunction with some of the addressing 
  *>    information). Some of the necessary identifier functions, especially 
  *>    to do with local operation of NSIS, may also be provided by lower 
  *>    layer signaling transport protocols. 
  *>     
  *> 4.5.3  NSLP Identification 
  *> 
  *>    Since the NTLP can be used to support several NSLPs, there is a need 
  *>    to identify which one a particular NSIS message is being used for: 
  *>     *) processing incoming messages at a responder - the NTLP should be 
  *>    able to demultiplex these towards the appropriate signaling 
  *>    application; 
  *>     *) processing general NSIS messages at an NSIS aware intermediate 
  *>    node - if the node does not handle the specific signaling 
  *>    application, it should be able to make a forwarding decision without 
  *>    having to parse the upper layer information. 
  *>     
  *>    Signaling application identifiers would probably require an IANA 
  *>    registry.  
  *>  
  *> 5. NSIS Protocol Interactions 
  *> 
  *>    So far as possible, the NSIS protocol should be usable in isolation, 
  *>    without explicitly depending on other protocols to operate. However, 
  *>    in many cases, NSIS functionality overlaps with the problem spaces of 
  *>    other protocols. In order to determine the boundaries which minimize 
  *>    any explicit interdependencies, these protocol interactions must be 
  *>    analyzed. 
  *>     
  *>    This is different from considering the use of NSIS protocols to 
  *>    support a particular signaling application, or example configurations 
  *>    in which NSIS might be deployed. These subjects are discussed in 
  *>    section 7. 
  *>                            
  *> 5.1 Resource Management Interactions 
  *> 

(See my overview message about this section).

...

  *>  
  *> 5.2 IP Routing Interactions 
  *> 
  *>    Several situations may occur when routing diverges from standard 
  *>    layer 3 routing. These are summarized in the sections below. 

There is a LOT more to say about routing interactions, even with
"standard layer 3 routing"!!

  *>     
  *> 5.2.1  Load Sharing 
  *> 
  *>    Load sharing or load balancing is a network optimization technique 
  *>    that exploits the existence of multiple paths to the same destination 
  *>    in order to obtain benefits in terms of protection, resource 
  *>    efficiency or network stability. The significance of load sharing in 
  *>    the context of NSIS is that, if the load sharing mechanism in use 
  *>    will forward packets on any basis other than source and destination 
  *>    address, routing of NSIS messages using end-to-end addressing does 
  *>    not guarantee that the messages will follow the data path. In this 
  *>    section, we briefly survey what standard methods have been used for 
  *>    load sharing within standard routing protocols. 
  *>     
  *>    In OSPF, load balancing can be used between equal cost paths [12] or 
  *>    unequal cost paths. An example of the latter approach is Optimized 
  *>    Multi Path (OMP). OMP discovers multiple paths, not necessarily equal 
  *>    cost paths, to any destinations in the network, but based on the load 
  *>    reported from a particular path, it determines which fraction of the 
  *>    traffic to direct to the given path. Incoming packets are subject to 
  *>    a (source, destination address) hash computation, and effective load 
  *>    sharing is accomplished by means of adjusting the hash thresholds. 
  *>     
  *>    BGP [13][14] advertises the routes chosen by the BGP decision process 
  *>    to other BGP speakers. In the basic specification, routes with the 
  *>    same Network Layer reachability information (NLRI) as previously 
  *>    advertised routes implicitly replace the original advertisement, 
  *>    which means that multiple paths for the same prefix cannot exist. 
  *>    Recently, however, a new mechanism was defined that will allow the 
  *>    advertisement of multiple paths for the same prefix without the new 
  *>    paths implicitly replacing any previous ones [15]. The essence of the 
  *>    mechanism is that each path is identified by an arbitrary identifier 
  *>    in addition to its prefix. 
  *>     
  *>    The distribution of traffic over the available path may be done per 
  *>    destination, per message in a round-robin fashion or with a 
  *>    predefined hashing function. The determination of the hashing image 
  *>    may take into account the source/destination IP address, QoS 
  *>    information such as the DSCP or protocol ID. When the routing 
  *>    decision is no longer based on the destination address only, however, 
  *>    there is a risk that data plane messages and control plane messages 
  *>    will not follow the same route. 
  *>     
  *> 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 27] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *> 5.2.2  QoS Routing 
  *> 
  *>    The are several proposals for the introduction of QoS awareness in 
  *>    the routing protocols. All of these essentially lead to the existence 
  *>    of multiple paths (with different QoS) towards the same destination. 
  *>    As such, they also contain an inherent risk for a divergence between 
  *>    control plane and data plane, similar to the load sharing case. 
  *>     
  *>    For intra-domain traffic, the difference in routing may result from a 
  *>    QoS-aware traffic engineering scheme, that e.g. maps incoming traffic 
  *>    to LSPs based on multi-field classification. In BGP, several 
  *>    techniques for including QoS information in the routing decision are 
  *>    currently proposed. A first proposal is based on a newly defined 
  *>    BGP-4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute 
  *>    is an optional transitive attribute that can be used to advertise a 
  *>    QoS route to a peer or to provide QoS information in along with the 
  *>    Network Layer Reachability Information (NLRI) in a single BGP update. 
  *>    A second proposal is based on controlled redistribution of AS routes 
  *>    [17]. It defines a new extended community (the redistribution 
  *>    extended community) that allows a router to influence how a specific 
  *>    route should be redistributed towards a specified set of eBGP 
  *>    speakers. The types of redistribution communities may result in a 
  *>    specific route not being announced to a specified set of eBGP 
  *>    speakers, that it should not be exported or that the route should be 
  *>    prepended n times. 
  *>     
  *> 5.2.3  Route pinning 
  *> 
  *>    Route pinning refers to the independence of the path taken by certain 
  *>    data packets from reachability changes caused by routing updates from 
  *>    an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway 
  *>    Protocol (BGP). This independence may for instance be caused by the 
  *>    configuration of static LSPs or by the establishment of explicitly 
  *>    routed LSPs by means of a signaling protocol (RSVP-TE or CR-LDP). If 
  *>    the NSIS signaling messages follow standard Layer 3 routing, this may 
  *>    cause a divergence between control plane and data plane. If 
  *>    reservations are made on the control plane, this may result in 
  *>    sending data along an unreserved path while maintaining a reservation 
  *>    on a path that is not used. 
  *>     
  *> 5.2.4  Route Changes 
  *> 
  *>    In this section, we will explore the expected interworking between a 
  *>    signaling for resource BGP routing updates, although the same applies 
  *>    for any source of routing updates. The normal operation of the NSIS 
  *>    protocol will lead to the situation depicted in Figure 5, where the 
  *>    reserved resources match the data path. 
  *>  
  *>  
  *>                     reserved +----+  reserved  +----+ 
  *>                      ------->| NF |----------->| NF | 
  *>                              +----+            +----+ 
  *>                   ===================================== 
  *>                                 data path 
  *>     
  *>                  Figure 5: Normal NSIS protocol operation 
  *>     
  *>    A route change (triggered by a BGP routing update for instance) can 
  *>    occur while such a reservation is in place. In case of RSVP, the 
  *>    route change will be installed immediately and any data that is sent 
  *>    will be forwarded on the new path. This situation is depicted 
  *>    Figure 6. 
  *>     
  *>                            Route update 
  *>                                 | 
  *>                                 v 
  *>                     reserved +----+  reserved  +----+ 
  *>                      ------->| NF |----------->| NF | 
  *>                              +----+            +----+ 
  *>                      ========== | 
  *>                              || |           +----+ 
  *>                              || +---------->| NF | 
  *>                              ||             +----+ 
  *>                              ============================ 
  *>                                data path 
  *>     
  *>                           Figure 6: Route Change 
  *>     
  *>    Resource reservation on the new path will only be started once the 
  *>    next control message is routed along the new path. This means that 
  *>    there is a certain time interval during which resources are not 
  *>    reserved on (part of) the data path. To minimize this time interval 
  *>    several techniques could be considered. As an example, RSVP [18] has 
  *>    the concept of local repair, where the router may be triggered by a 
  *>    route change. In that case the RSVP node can start sending PATH 
  *>    messages directly after the route has been changed. Note that this 
  *>    option may not be available for NSIS if no per-flow state is kept in 
  *>    the NF. 
  *>     
  *>    It is not guaranteed that the new path will be able to provide the 
  *>    same guarantees that were available on the old path. Therefore, in a 
  *>    more desirable scenario, the NF should wait until resources have been 
  *>    reserved on the new path before installing the route change. The 
  *>    route change procedure then consists of the following steps: 
  *>     1. NF receives a route announcement, 
  *>     2. Refresh messages are forwarded along the current path, 
  *> 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 29] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>     3. A copy of the refresh message is remarked as request and send 
  *>    along the new path that was announced, 
  *>     4. When the NF has been acknowledged about the reservations on the 
  *>    new path the route will be installed and the traffic will flow along 
  *>    the new path. 
  *>     
  *>    Another example related to route changes is denoted as severe 
  *>    congestion and is explained in [19]. This solution adapts to a route 
  *>    change, when a route change creates a congestion on the new routed 
  *>    path. 
  *>     
  *> 5.2.5  Router Redundancy 
  *> 
  *>    In some environments, it is desired to provide connectivity and per 
  *>    flow or per class resource management with high-availability 
  *>    characteristics, i.e. with rapid transparent recovery even in the 
  *>    presence of route changes. This may involve interactions with the 
  *>    basic protocols which are used to manage the routing in this case, 
  *>    such as VRRP [20]. A future version of this document may consider 
  *>    interactions between NSIS and such protocols in support of high 
  *>    availability functionality. 
  *>  
  *> 5.3 Mobility Interactions 
  *> 
  *>    The interactions between mobility and resource signaling protocols 
  *>    have been extensively analyzed in recent years, primarily in the 
  *>    context of RSVP and Mobile IP interaction (e.g. [21]), but also in 
  *>    the context of other types of network (e.g. [22]). This analysis work 
  *>    has shown that some difficulties in the interactions are quite deep 
  *>    seated in the detailed design of these protocols; however, the 
  *>    problems and their possible solutions fall under five broad headings. 
  *>    The main issue is to limit the period after handovers during which 
  *>    the resource state has not been installed on the path, in particular 
  *>    the new part of the path. 
  *>     
  *>    We can use this work as the starting point for considering the 
  *>    framework aspects of a new signaling protocol like NSIS, which will 
  *>    need to interwork with mobility signaling, from Mobile IP to mobility 
  *>    paradigms based on micromobility or application layer approaches. 
  *>     
  *> 5.3.1  Addressing and Encapsulation 
  *> 
  *>    A mobility solution typically involves address reallocation on 
  *>    handover (unless a network supports per host routing) and may involve 
  *>    special packet formats (e.g. the routing header and Home Address 
  *>    option of MIPv6). Since NSIS may depend on end system addresses for 
  *>    forwarding signaling messages and defining flows (section 4.5.1), the 
  *>    special implications of mobility for addressing need to be 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 30] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>    considered. Examples of possible approaches that could be used to 
  *>    solve the addressing and encapsulation problem are as follows: 
  *>     *) Use a flow identification based on low level IP addresses (e.g. 
  *>    the Care of Address) and other 'standard' fields in the IP header. 
  *>    This makes least demands on the packet classification engines within 
  *>    the network. However, it means that even on a part of the flow path 
  *>    which is unchanged, the reservation will need to be modified to 
  *>    reflect the changed flow identification (see section 5.3.3). 
  *>     *) Use a flow identification that does not change (e.g. based on 
  *>    Home Address); this is the approach assumed in [23]. This simplifies 
  *>    the problem of reservation update, at the likely cost of considerably 
  *>    complicating the flow identification requirements. 
  *>     
  *>    In the first approach, to prevent double reservation, NSIS nodes need 

I wonder about the emphasis on double reservation.  It is unclear to me
that this is really a primary issue.  I understand that these networks
are typically under-provisioned (though I wonder how long that will be
true as the technology continues to mature), but that can be
statistically compensated for by a bit of over-booking ;-) oops, sorry,
I meant optimistic reservation.  It seems quite possible to me that one
can get good enough service, with much simpler protocols, if you just
forget about the double-reservation problem.  A combination of local
repair, timeouts, and judicious optimistic reservation might work most
of the time.  Are there simultation results on these questions?

  *>    to be able to recognize that a reservation with the new flow 
  *>    identifier is to be correlated with an existing one. The reservation 
  *>    identifier (section 4.5.2) was introduced for exactly this purpose. 
  *>    Note that this would require the reservation identifier to have 
  *>    (secure) end to end significance. (An additional optimization here 
  *>    would be use a local mobility management scheme to localize the 
  *>    visibility of the address change.) 
  *>     
  *>    The feasibility and performance of this first approach needs to be 
  *>    assessed, including a detailed analysis of the signaling scenarios 
  *>    after a handover. However, given the high impact of requiring more 
  *>    sophisticated packet classifiers, initially it still seems more 
  *>    plausible than the second approach. This implies that the NSIS 
  *>    initiator should define flows in terms of real (care of) addresses 
  *>    rather than virtual (home) addresses. Thus, it would have detailed 
  *>    access to lower layer interface configuration (cf. section 4.1), 
  *>    rather than operating as a pure application level daemon as is 
  *>    commonplace with current RSVP implementations. 
  *>     
  *> 5.3.2  Localized Path Repair 
  *> 
  *>    In any mobility approach, a handover will cause at least some changes 
  *>    in the path of upstream and downstream packets. NSIS needs to install 
  *>    new state on the new path, and remove it on the old. Provided that 
  *>    some NSIS node on the joined path - the crossover router - can 
  *>    recognize this situation (which again depends on reservation 
  *>    identification), state installation and teardown can be done locally 
  *>    between it and the mobile node. (This may have implications for which 
  *>    entities are allowed to generate which message types, see section 
  *>    4.3.2). It seems that the basic NSIS framework already contains the 
  *>    fundamental components necessary for this. 
  *>     
  *>    A critical point here is the signaling that is used to discover the 
  *>    crossover router. This is a generalization of the problem of finding 
  *>    next-NSIS-hop nodes: it requires extending the new path over several 
  *>    hops until it intersects the old one. This is easy for uplink traffic 
  *>    (where the mobile is the sender), but much harder for downlink 
  *>    traffic without signaling via the correspondent. There is no reason 
  *>    for the crossover routers for uplink and downlink flows to be the 
  *>    same, even for the same correspondent. The problem is discussed 
  *>    further in [24]. 
  *>     
  *> 5.3.3  Reservation Update on the Unchanged Path 
  *> 
  *>    On the path between the crossover router(s) and the correspondent, it 
  *>    is necessary to avoid, if possible, double reservations, but rather 

Ditto.

  *>    to update the reservation state to reflect new flow identification 
  *>    (if this is needed, which is the default assumption of section 
  *>    5.3.1). Examples of approaches that could be used to solve this 
  *>    problem are the following: 
  *>     *) Use a reservation state definition that does not change even if 
  *>    the flow definition changes (see Section 4.5.2). In this case this 
  *>    problem is solved. 
  *>     *) Use signaling all the way to the correspondent node (receiver end 
  *>    host), accepting the additional latency that this might impose. 
  *>     *) Use an NSIS-capable crossover router that manages this 
  *>    reservation update autonomously (more efficiently than the end 
  *>    nodes), with similar considerations to the local path repair case. 
  *>     
  *> 5.3.4  Interaction with Mobility Signaling 
  *> 
  *>    In existing work on mobility protocol and resource signaling protocol 
  *>    interactions, several framework proposals describing the protocol 
  *>    interactions have been made. Usually they have taken existing 
  *>    protocols (Mobile IP and RSVP respectively) as the starting point; it 
  *>    should be noted that an NSIS protocol might operate in quite a 
  *>    different way. In this section, we provide an overview of how these 
  *>    proposals would be reflected in framework of NSIS. The mobility 
  *>    aspects are described using Mobile IP terminology, but are generally 
  *>    applicable to other network layer mobility solutions. The purpose of 
  *>    this overview is not to select or prioritise any particular approach, 
  *>    but simply to point out how they would fit into our framework and any 
  *>    major issues with them. 
  *>     
  *>    We can consider that two signaling processes are active: mobility 
  *>    signaling (e.g. binding updates or local micromobility signals) and 
  *>    NSIS. The discussion so far considered how NSIS should operate. There 
  *>    is still a question of how the interactions between the NSIS and 
  *>    mobility signaling should be considered. 
  *>     
  *>    The basic case of totally independent specification and 
  *>    implementation seems likely to lead to ambiguities and even 
  *>  
  *>  
  *> Hancock et al.            Expires - May 2003                 [Page 32] 
  *>                   Next Steps in Signaling: Framework     November 2002   
  *>  
  *>    interoperability problems (see [23]). At least, the addressing and 
  *>    encapsulation issues for mobility solutions that use virtual links or 
  *>    their equivalents need to be specified in an implementation-neutral 
  *>    way. 
  *>     
  *>    A type of 'loose' integration is to have independent protocol 
  *>    definitions, but to define how they trigger each other - in 
  *>    particular, how the mobility protocol triggers NSIS to send 
  *>    refresh/modify/tear messages. A pair of implementations could use 
  *>    these triggers to improve performance, primarily reducing latency. 
  *>    (Existing RSVP modification consider the closer interaction of making 
  *>    the RSVP implementation mobility-routing aware, e.g. so it is able to 
  *>    localize refresh signaling; this would be a self contained aspect of 
  *>    NSIS.) This information could be developed for NSIS by analyzing 
  *>    message flows for various mobility signaling scenarios as was done 
  *>    in [21]. 
  *>     
  *>    An even tighter level of integration is to consider a single protocol 
  *>    carrying both mobility and resource information. Logically, there are 
  *>    two cases: 

Wow.  Well, yes, it's possible. but ...

This is really a special case of the general issue that we faced when
we first started RSVP design in 1992 -- how should routing and
reservation relate?  It was perfectly clear that we could do
reservation by adding enough machinery to OSPF, but that did not seem
to be a feasible approach.  Besides the difficulty of getting it
through the IETF, implemented, and deployed, there was a realistic fear
the that resulting OSPF would fall over from sheer complexity.  Besides,
we would then have to modify EVERY routing protocol to do reservation,
and that seemed totally unrealistic.  So we kept them separate, but
this led to ugly things like route pinning and QoR routing, and really
making it work is still a largely unsolved technical problem.

This subject is HARD.

  *>     1. Carry mobility routing information (a 'mobility object') in the 
  *>    resource messages, as is done in [23]. (The prime purpose in this 
  *>    approach is to enable crossover router discovery.) 
  *>     2. Carry resource signaling in the mobility messages, typically as a 
  *>    new extension header. This was proposed in [25] and followed up 
  *>    in [26]; [27] also anticipates this approach. In our framework, we 
  *>    could consider this a special case of NSIS layering, with the 
  *>    mobility protocol playing the role of the signaling transport (as 
  *>    in 4.3.1). 
  *>    The usefulness of this class of approach depends on a tradeoff 
  *>    between specification simplicity and performance. Simulation work is 
  *>    under way to compare the performance of the two approaches in the 
  *>    case of RSVP and micromobility protocols. 
  *>     
  *>    Other modes of interaction might also be possible. The critical point 
  *>    with all these models is that the general solutions developed by NSIS 
  *>    should not depend fundamentally on the choice of any particular 
  *>    mobility protocol. Especially if it has interdomain scope, tight 
  *>    integration would have major deployment issues (even loose 
  *>    integration could require NSIS implementations to hook into multiple 
  *>    different mobility protocols). Therefore, any tightly integrated 
  *>    solution should be considered out of scope of initial NSIS 
  *>    development, and even in the long term is probably only applicable if 
  *>    it can be localized within a particular part of the network. 
  *>   
  *> 
  *>  
  *> 5.3.5  Interaction with Fast Handoff Support Protocols 
  *> 
  *>    In the context of mobility between different access routers, it is 
  *>    common to consider performance optimizations in two areas: selection 
  *>    of the optimal access router to handover to, and transfer of state 
  *>    information between the access routers to avoid having to regenerate 
  *>    it in the new access router after handover. The seamoby working group 
  *>    is developing solutions for these protocols for pure IP based 
  *>    networks (CARD[28] and CT[29] respectively); other networks, which 

Huh? We are developing signaling for "pure IP-based networks"; what
other kind would be the subject of an IETF working group? 

  *>    use NSIS for resource signaling within the network, may use different 
  *>    types of solution. 
  *>     
  *>    In this section, we consider how NSIS should interact with these 
  *>    functions, however they are implemented. Detailed solutions are not 
  *>    proposed, but the way in which interaction these functions is seen 
  *>    within the NSIS framework is described. NSIS should be able to 
  *>    operate independently of these protocols. However, significant 
  *>    performance gains could be achieved if they could be made to 
  *>    cooperate. In addition, the resource signaling aspects of these 
  *>    protocols could profitably use a common set of resource types and 
  *>    definitions, since they will probably be supporting the same overall 
  *>    signaling application. 
  *>     
  *>    The question arises, what the mode of interaction should be: 
  *>    independent operation, NSIS triggering access router discovery and 
  *>    state transfer, or vice versa. The questions for the two cases seem 
  *>    to be independent. 
  *>     
  *>    For access router discovery, a typical model of operation is that the 
  *>    mobile carries out an information gathering exercise about a range of 
  *>    capabilities. In addition, where those capabilities relate purely to 
  *>    the AR and mobile, there is no role for NSIS (its special 
  *>    functionality is not relevant). However, considering resource 
  *>    aspects, one aspect of the AR 'capability' is resource availability 
  *>    on the path between it and the correspondent, and NSIS should be able 
  *>    to fulfill this part. Indeed, this is effectively precisely the 
  *>    application considered in [26], where it is a sort of special case of 
  *>    resource signaling during handover. 
  *>     
  *>    Therefore, a possible model of access router discovery/NSIS 
  *>    relationship is that some entity in a candidate AR triggers NSIS 
  *>    using resource and reservation information (including reservation id) 
  *>    from the current AR to find out about what would be available on the 
  *>    new path. Note that this should be a query rather than an actual 
  *>    reservation; this semantic could be included either in the NTLP or 
  *>    NSLP. 
  *>  
  *>    The case of state transfer is more complex. There are two obvious 
  *>    options, corresponding to whether one transfers just signaling 
  *>    application state or NSIS state as well: 
  *>     1. "State transfer triggering NSIS": A state transfer process passes 
  *>    the 'raw' resource state to the new AR. This triggers a new instance 
  *>    of NSIS to request that resource. 
  *>     2. "NSIS using state transfer": NSIS transfers its own state 
  *>    information from the old to the new AR. It can then carry out the 
  *>    same update signaling as though it was a single 'virtual AR' which 
  *>    had just had a topology change towards the correspondent. (This is 
  *>    essentially the conceptual model of [21].) 
  *>     
  *>    The first model is simpler, and maybe more in line with the basic 
  *>    state transfer expectation; however, it seems hard to avoid double 
  *>    reservations since the two NSIS protocol instances are not 
  *>    coordinated. Therefore, the second model seems more appropriate. An 
  *>    advantage of the 'virtual AR' model is that it ensures that the 
  *>    impact of the interaction is limited to the NSIS instances at ARs 
  *>    themselves, since the rest of the network must be able to handle a 
  *>    topology change anyway. 
  *>  
  *>    Note that there is an open issue of who is responsible between the 
  *>    mobile and AR to decide that the state transfer procedures have not 
  *>    happened for whatever reason - e.g. because they were not even 
  *>    implemented - and take recovery action to have the mobile refresh 
  *>    reservations promptly. It appears this has to be an NSIS 
  *>    responsibility in the AR, and probably requires a custom notification 
  *>    message for this circumstance. 
  *>     
  *> 5.4 NSIS Interacting with NATs 
  *> 
  *>    Because at least some NSIS messages will almost inevitably contain 
  *>    address and possibly higher layer information as payload (see section 
  *>    4.5.1), we must consider the interaction between NSIS and address 
  *>    translation devices (NATs). As well as 'traditional' NATs of various 
  *>    types (as defined in [30]) very similar considerations would apply to 
  *>    some IPv4/v6 transition mechanisms such as SIIT [31]. 
  *>     
  *>    In the simplest case of an NSIS unaware NAT in the signaling path, 
  *>    payloads will be uncorrected and the signaling will be for the 
  *>    incorrect flow. Applications could attempt to use STUN [32] or 
  *>    similar techniques to detect and recover from the presence of the 
  *>    NAT. Even then, NSIS would have to use a well known encapsulation 
  *>    (TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end 
  *>    NAT devices. 

I *LIKE* it!  Listen up, Melinda.  We need NSIS over HTTP, clearly!

  *>     
  *>    A simple 'NSIS-aware' NAT would require flow identification 
  *>    information to be in the clear and not integrity protected. An 
  *>    alternative conceptual approach is to consider the NAT functionality 
  *>    being part of NSIS message processing itself, in which case the 
  *>    translating node can take part natively in any NSIS security 
  *>    mechanisms. Depending on NSIS layering, it could be possible for this 
  *>    processing to be done in an NSIS node which was otherwise ignorant of 
  *>    any particular NSIS signaling applications. 
  *>     
  *>    Note that all of this discussion is independent of the use of NSIS 
  *>    for general control of NATs (and firewalls). This is considered in 
  *>    section 7.4. 
  *>     
  *> 6. Security and AAA Considerations 
  *> 
  *>    A framework is meant to create boundaries for a later protocol and to 
  *>    describe the interaction between the protocol and its environment. 
  *>    Security issues usually turn out to have impacts in the interaction 
  *>    of these protocols and must therefore be appropriately addressed in 
  *>    such a framework. This section describes these general security 
  *>    issues, and in particular considers the interactions between NSIS and 
  *>    authentication, authorization and accounting. Together with 
  *>    authentication the protection of the signaling messages is addressed 
  *>    - namely replay and integrity protection.  
  *>     
  *>    An initial analysis of the major security threats that apply in the 
  *>    typical of scenario where NSIS is expected to be used is given in 
  *>    [5]; these threats are described at the overall scenario level, in 
  *>    terms of the impact on users and networks. However, in any given 
  *>    scenario, NSIS will be just one part of the overall solution. 
  *>    Ultimately, the framework will need to define which of these threats 
  *>    need to be handled by NSIS (and which parts of NSIS) and which by the 
  *>    other components. Currently, we can only make initial scoping 
  *>    assumptions of this sort.  
  *>     
  *> 6.1 Authentication 
  *> 
  *>    Authentication and key establishment for a signaling protocol should 
  *>    be seen as a two-phase process. The first-phase is usually more 
  *>    performance intensive because of a larger number of roundtrips, 
  *>    denial of service protection, cross-realm handling, interaction with 
  *>    other protocols and the likely larger cryptographic computation 
  *>    associated with it. As stated in section 4.3, this functionality 
  *>    could be provided externally to NSIS, e.g. by reusing a standard 
  *>    protocol which already included this functionality. 
  *>     
  *>    At the end of this phase it should be possible to create or derive 
  *>    security associations that are usable for the protection of the NSIS 
  *>    signaling messages themselves. The functionality required here 
  *>    relates to (data origin) authentication (including integrity and 
  *>    replay protection) of individual signaling messages. Key 
  *>    establishment, rekeying, synchronization issues are issue that may be 
  *>    addressed here depending on the specific method. In any case the 
  *>    protection applied to each signaling message must be fast and 
  *>    efficient. 
  *>     
  *>    When using cryptography to protect signaling messages, it is obvious 
  *>    that a node must be able to select the appropriate security 
  *>    association in order to be able to apply signaling message 
  *>    protection. This should just be a general point about endpoint 
  *>    identity issues. Hence the identifier must be available to the 
  *>    transmitting node. Regarding identities there is a need to support 
  *>    different identity types to enable the flexible usage of several 
  *>    signaling initiators and receivers. Supporting static configuration 
  *>    and dynamic learning of these identities should be provided.  
  *>     
  *> 6.2 Authorization 
  *> 
  *>    Authorization information can be seen in an abstract form as "Can the 
  *>    resource requestor be trusted to pay for the reservation?". This 
  *>    abstraction is supported by the fact that reservations require some 
  *>    form of incentive to use some 'default' resource (or vice versa - 
  *>    penalty for not reserving too many resources). In general, the 

I think the sense of this sentence is reversed, else I am seriously confused.

  *>    semantics of the authorisation will depend on the signaling 
  *>    application in use. The implication of this is that NSIS will not 
  *>    directly make authorisation decisions; instead, the authorisation 
  *>    information must be fed into the resource management function 
  *>    (section 5.1) which actually decides on the request. 
  *>     
  *>    Some negotiation needs to take place to determine which node will 
  *>    take responsibility for authorising a resource request, the 
  *>    implication being that the same node will ultimately be accounted to 
  *>    for it. Such a negotiation needs to be flexible enough to support 
  *>    most currently deployed schemes (e.g. reverse charging, etc.) while 
  *>    keeping efficiency and simplicity in mind. This negotiation might be 
  *>    executed before starting resource signaling (assumed in section 4.2), 
  *>    although it could also be part of the NSIS signaling messages (as in 
  *>    some proposals dealing with charging and RSVP). Since information 
  *>    needs to be sent to the networks, some information needs to be 
  *>    included to provide the network with the necessary information to 
  *>    start the authorisation process. Hence fully opaque objects might not 
  *>    always be the proper choice.  
  *>     
  *>    It is not clear if 'initiation' of a reservation is related to 
  *>    willingness to accept authorisation responsibility. (Current 
  *>    practices tend to assume that flow originators are responsible.) In 
  *>    any case, it seems unlikely that a domain will make a cost-incurring 
  *>    request of a peer domain without already having received a matching 
  *>    request from the peer in the other direction - in other words, 
  *>    requests must propagate between domains in the same direction as 
  *>    authorisation responsibility. 

Doesn't Reverse-Charging violate this?

  *>     
  *>    If this argument is correct, and if NSIS initiation and authorisation 
  *>    responsibility are decoupled, it must be possible for the 
  *>    authorisation responsibility to propagate both in the direction 
  *>    initiator->responder and vice versa. Also, if both [flow] sender and 
  *>    receiver initiation are possible, service descriptions must include 
  *>    information about the authorisation policy to be applied, which must 
  *>    be imposed consistently along the whole path. These issues should be 
  *>    analyzed to determine if 1, 2 or 4 alternative scenarios are possible 
  *>    and realistic. 
  *>     
  *>    A second question is that of which entities actually authorise which. 
  *>    One end user must ultimately get authorisation for the request (this 
  *>    may or may not be assumed to be the NSIS initiator, see below). There 
  *>    are then two possible models for how this authorisation is done 
  *>    throughout the path. 
  *>     
  *>    The first model assumes that each network along the path is able to 
  *>    authenticate and authorise the user directly. The implication for a 
  *>    signaling protocol is that the user credentials cannot be removed 
  *>    after the first hop and have to be further included in the message 
  *>    when forwarded to other networks. Every node along the path is then 
  *>    able to verify the user and to provide policy based admission 
  *>    control. 
  *>     
  *>    The second model assumes that the user credentials are removed at the 
  *>    first hop. The first network knows the user identity requesting the 
  *>    resources but does not include this information further along the 
  *>    path. The first network can therefore be seen as acting on behalf of 
  *>    the originator to take responsibility to enable further reservations 
  *>    to be done along the path i.e. in particular to the next network 
  *>    only. This procedure is then applied on a hop-by-hop basis.  
  *>     
  *>    Note that both models are independent of whether a traditional 
  *>    subscription based approach or an alternative means of payment (such 
  *>    as pre-pay on on-line charging by the visited network) is used. These 
  *>    issues only have an impact for the transmission of accounting records 
  *>    and for a requirement to execute an online verification whether a 
  *>    user still has sufficient credits/funds; therefore, these details do 
  *>    not affect NSIS operation. 
  *>     
  *> 6.3 Accounting 
  *> 
  *>    It is obvious that accounting/charging is an important part for the 
  *>    success and the acceptance of a resource signaling protocol. Most of 
  *>    the thinking in this area is derived from the specific case of 
  *>    signaling for QoS; however, we make an initial working assumption 
  *>    that the same paradigm should apply to any signaling application for 
  *>    which accounting is necessary. We make the general assumption here 
  *>    that accounting records are generated by the resource management 
  *>    function based entirely on traffic measurements and processed in 
  *>    accordance with the authorisation information that was used in 
  *>    deciding to grant the request in the first place. 

This approach might be applicable in some cases, but it seems likely
that charging will more often depend upon reservations, so that the
signaling protocol will need to participate in the charging.

  *>     
  *>    Therefore, NSIS plays no further part in this activity; the 
  *>    accounting records are transmitted using the AAA infrastructure, and 
  *>    charging and billing for the overall service is carried out at some 
  *>    higher layer. This would include feedback to applications (and users) 
  *>    about total session cost (of which the network resource cost might be 
  *>    only a part). An open issue is whether a query (without actually 
  *>    making a reservation) to the network should also generate a 
  *>    chargeable event; this could be considered as an aspect of the 
  *>    service definition. 
  *>     
  *> 6.4 End-to-End vs. Peer Relationship Protection 
  *> 
  *>    It is reasonable to assume that peer relationship security (with 
  *>    chain-of-trust) is used for most signaling environments relevant to 
  *>    NSIS. Especially the separation of signaling into different network 
  *>    parts (intra-domain within the access network, end-node to access 
  *>    network, intra-domain, and so on) and new proposals regarding 
  *>    mobility and proxy support show that traditional end-to-end signaling 
  *>    is not applicable in every environment (or possibly only in a minor 
  *>    number of environments). End-to-end security in a signaling protocol 
  *>    is actually problematic for two reasons:  
  *>     
  *>     1. Even if the messages use the address of the end-host (to support 
  *>    routing), the messages still have to be interpreted and modified 
  *>    along the path.  
  *>     
  *>     2. The only property that can be achieved by using end-to-end 
  *>    security is that one end-host can be assured that the other end-host 
  *>    included some parameters (possibly resource parameters) that have not 
  *>    been modified along the path. Nodes along the path usually do not 
  *>    have the possibility to cryptographically verify the protected 
  *>    message parts. If the two end-points negotiate which side has to pay 
  *>    for the reservation (or possibly how much and other parameters) 
  *>    within the signaling protocol then there is a need to protect this 
  *>    information. This leads to the question which protocols are executed 
  *>    before the signaling message exchange starts. If resource parameters 
  *>    and payment/charging related information are already exchanged 
  *>    beforehand as part of a separate protocol (possibly SIP) then there 
  *>    at the NSIS level basis. In most cases an opaque token to link the 
  *>    different protocols may be sufficient. 
  *>  
  *> 7. NSIS Application Scenarios 
  *> 
  *>    This section considers various application scenarios or deployment 
  *>    configurations for NSIS. Our goal is that an NSIS protocol designed 
  *>    according to the framework presented in the previous sections should 
  *>    be able to support these scenarios if implemented appropriately; 
  *>    therefore, this section does not form part of the framework 
  *>    definition, but rather provides examples of how NSIS can be used to 
  *>    do something interesting. In the long term, some of this material may 
  *>    be contained in specific NSIS applicability statements. 
  *>  
  *> 7.1 NSIS and Existing Resource Signaling Protocols 
  *> 
  *>    It is hoped that NSIS could eventually achieve widespread use for 
  *>    resource signaling. However, it is bound to have to inter-operate 
  *>    with existing resource signaling protocols at least during transition 
  *>    and possibly long term. The prime example for QoS is RSVP, although 
  *>    other proprietary or domain specific protocols (e.g. bandwidth broker 
  *>    related) may also be considered. A related issue is that NSIS will be 
  *>    only one part of the solution: it will always need to interwork with 
  *>    other resource-related protocols (e.g. COPS). 

Policy control, ...  -- need refs here.

  *>     
  *>    Analyzing the constraints on NSIS that come from these requirements 
  *>    is hard before further refinement of the framework has been carried 
  *>    out and critical assumptions pinned down. However, we can identify 
  *>    various modes of interoperation, and the attributes of the framework 
  *>    that will make them easy. 
  *>     
  *>    Firstly, we allow for NSIS use over a 'long range', in conjunction 
  *>    with a different protocol locally (e.g. intra-domain); or, the two 
  *>    roles could be reversed. This is actually very similar to the case of 
  *>    use of NSIS layered over itself (section 7.5). In the case where the 
  *>    'inter-layer' interaction is mediated via resource management, the 
  *>    same should approach should work with non-NSIS protocols. What needs 
  *>    to be validated here is whether NSIS layering requires the exchange 
  *>    of NSIS specific information between the layers. 
  *>     
  *>    A second issue is that NSIS should be deployable within an 
  *>    environment without radical changes to supporting resource (or AAA) 
  *>    related protocols. The main issue here is that NSIS should be 
  *>    flexible in its ability to support different service definitions (and 
  *>    possibly flow classifications). This is already one of the main goals 
  *>    of the framework presented here.  
  *>  
  *>    The final point is that it should be possible to use NSIS over one 
  *>    network region, concatenated with another protocol over an adjacent 
  *>    region. The main issue here, apart from the flexible service and flow 
  *>    capabilities already mentioned, is that NSIS should be adaptable in 
  *>    what it assumes about signaling paths (e.g. to interwork with both 
  *>    path-coupled and decoupled solutions), and in initiation paradigms 
  *>    (e.g. to interwork with sender and receiver initiated solutions). 
  *>  
  *> 7.2 NSIS Supporting Centralized QoS Resource Management 
  *> 

See the comments on RMF in my overview message.

  *>    One area of application for the NSIS protocol is for QoS resource 
  *>    reservation and provisioning. The NSIS protocol may be used to 
  *>    provide intra-domain or inter-domain QoS bandwidth reservation setup 
  *>    by means of its interaction with the RMF. In what follows we assume 
  *>    that the NEs are colocated with an admission control entity that has 
  *>    a logical (abstract) view on the resources managed by the RMF, as 
  *>    described in section 5.1. 
  *>     
  *>    The NEs in a domain can interface with an RMF managing the complete 
  *>    domain, in which case, the abstract topology view provided between 
  *>    NSIS and RMF can be formalized as a Service Level Agreement (SLA). 
  *>    This situation is depicted schematically in Figure 7. 

It is not clear to me that this makes sense.  However, if you are going
to talk about this, you need to reference the SLS work
draft-tequila-sls-00.txt.

  *>     
  *>              +----+   NSIS     +-----+    NSIS     +----+  
  *>              | NI |============| NF  |=============| NR |  
  *>              +----+            +-----+             +----+ 
  *>                                   | 
  *>                                   | SLA  
  *>                                   | 
  *>                                +------+ 
  *>                                | RMF  | 
  *>                                +------+ 
  *>     
  *>        Figure 7: Resource Reservation using RMF as a Server to NSIS 
  *>                                                        
  *>    In case of centralized RMF, the SLA or its technical part, the 
  *>    Service Level Specification (SLS) [33] specifies the resource 
  *>    guarantees that the RMF needs to provide to the NF. These guarantees 
  *>    apply between one or more ingress and egress points of the network. 
  *>    The SLS also specifies the availability and reliability of the 
  *>    service. In the case of QoS signaling, it may refer to a bandwidth 
  *>    service with certain performance guarantees regarding delay, jitter 
  *>    or packet loss. The SLS interface can be automated by means of an SLS 
  *>    negotiation protocol. This allows for more dynamical SLS 
  *>    modifications and the exchange of notification messages with the NF. 
  *>    These can for instance be used to provide monitoring feedback from 
  *>    the RFM to the NF.    
  *>  
  *>    The decoupling of NSIS signaling and network management by means of 
  *>    an SLS has some attractive properties: 
  *>     *) It allows a Network Provider to easily share the use of its 
  *>    infrastructure between several Service Providers using NSIS signaling 
  *>    to provide their service. 
  *>     *) It allows a clear separation between resource provisioning and 
  *>    management and reservation signaling and admission control. 
  *>     *) It relieves the NF from several tasks, making it potentially more 
  *>    scalable in the core of the network. 
  *>     
  *>    The NF can perform either per-flow or per-class admission control 
  *>    decisions based on the requested QoS information and on the 
  *>    reservation state it keeps regarding active flows (or classes). 
  *>    Keeping per-flow state may be required for policing, 
  *>    accounting/billing and explicit reservation teardown. These functions 
  *>    are mandatory in the access or edge of the network. Conveniently, 
  *>    this is also where the processing needed to maintain per-flow state 
  *>    will remain manageable. In the core, this approach may not scale very 
  *>    well and per-class state may be used as an alternative that is very 
  *>    scalable and allows for a lightweight processing of signaling 
  *>    messages. With per-class state, however, we lose the ability to 
  *>    directly notify the NI in case of unsolicited network events because 
  *>    the affected flows cannot be identified. Instead, the NI needs to be 
  *>    indirectly notified in response to a refresh message which in turn 
  *>    mandates the use of soft-state with separate messages or message 
  *>    structure for requests and refreshes. 
  *>     
  *>    The RMF can execute its network provisioning functions according to 
  *>    its internal policies. In the easiest case, it may run an 
  *>    overprovisioned network with only monitoring capabilities in order to 
  *>    follow up on the delivered performance. In more complex scenarios, it 
  *>    may use a whole array of network optimization tools in order to 
  *>    deliver and maintain service quality according to the SLS. This may 
  *>    require network monitoring, the installation and use of appropriate 
  *>    protection mechanisms and providing feedback regarding actual traffic 
  *>    performance to the NSIS entity. 
  *>     
  *>    Alternatively, the NSIS protocol may be used for resource 
  *>    provisioning. In that case, the RMF acts as a client towards the NSIS 
  *>    protocol, as a particular "application" triggering an NI for 
  *>    resources in the network. This situation is depicted in Figure 8. 
  *>     
  *>                                +------+ 
  *>                     +----------| RMF  |----------+ 
  *>                    /           +------+           \ 
  *>                   /                                \ 
  *>                  /                                  \ 
  *>                 /                                    \ 
  *>              +----+   NSIS     +-----+    NSIS     +----+  
  *>              | NI |============| NF  |=============| NR |  
  *>              +----+            +-----+             +----+ 
  *>     
  *>                  Figure 8: NSIS for Resource Provisioning 
  *>     
  *>    In this case the RMF is providing traffic classification and 
  *>    conditioning functions. An example of such functionality is described 
  *>    in [34]. The packet "classifiers" select the packets in a traffic 
  *>    stream based on the content of some portion of the packet header. The 
  *>    traffic "conditioner" performs metering, shaping, policing, 
  *>    scheduling and/or re- marking of packets to ensure that the traffic 
  *>    entering a node conforms to a certain predefined policy. 
  *>     
  *> 7.3 NSIS Supporting Distributed Resource Management 
  *> 
  *>    Section 7.2 described the situation where NSIS is supporting a 
  *>    centralized RMF. This section introduces the situation where NSIS is 
  *>    supporting a distributed RMF. When the RMF is distributed in the 
  *>    network, a protocol for communication with the NI, NF, NR may not be 
  *>    required. In this case the RMF is providing traffic classification 
  *>    and conditioning functions; an example of such functionality is 
  *>    described in [34]. Figure 9 shows how a distributed RMF could 
  *>    interact with the NSIS protocol. 
  *>     
  *>      +----+   NSIS   +-----+    NSIS   +-----+   NSIS   +----+   
  *>      | NI |==========| NF  |====...====| NF  |==========| NR |     
  *>      +----+          +-----+           +-----+          +----+  
  *>      +----+          +-----+           +-----+          +----+  
  *>      |RMF |          | RMF |           | RMF |          |RMF |  
  *>      +----+          +-----+           +-----+          +----+   
  *>     
  *>               Figure 9: Distributed RMF as a server for NSIS 
  *>

This figure seems more correct than Figure 1 -- and should
probably replace Fig 1.

  *> 7.4 NSIS for Middlebox Signaling 
  *> 
  *>    As well as the use for 'traditional' QoS signaling, it should be

####    Another possible application of the signaling protocol to set up
####    flow-related state in middleboxes (firewalls, NATs, etc.)
 
  *>    possible to use NSIS to set up flow-related state in middleboxes 
  *>    (firewalls, NATs, and so on). Requirements for such communication are 
  *>    given in [35], and initial discussions of NSIS-like solutions are 
  *>    contained in [36], [37] and [38]. A future version of this document 
  *>    may contain more details on how an NSIS should be used for this type 
  *>    of signaling application. 
  *>     
  *> 7.5 Multi-Level NSIS Signaling 
  *> 

Multi-level signaling might be a good idea, and there is a literature
on it going back to Banerjea at Berkeley 10 years ago (the Tenet
system), as well as Lixia Zhang's more recent mulit-level signaling
model.  A little bit of scholarship would pay dividends here. This
section feels like too much top-down abstraction and boxes with lines,
and not a clear intellectual model that fits the real world of
networking.  I think the real world connection is lurking, but it is
hidden in layerist abstraction here.

  *>    This section describes a way of separating the NSIS signaling 
  *>    protocol into more than one hierarchical level. In this section three 
  *>    levels of hierarchy are considered (see Figure 10); however, the 
  *>    approach is quite general to more (or fewer) levels: the important 
  *>    issue is the use of NSIS at more than one level at all. 
  *>     
  *>    The lowest hierarchical level ("level 1") provides basic resource 
  *>    management functionality related to scalable, simple and fast soft 
  *>    state maintenance and to transport functions, such as reliable 
  *>    delivery of signaling messages, congestion control notification and 
  *>    load sharing adaptation. Soft state that is maintained by this level 
  *>    is usually per traffic class based. 
  *>     
  *>    The second hierarchical level ("level 2") is more complex than level 
  *>    1 as regards soft state maintenance. Soft state maintained by this 
  *>    hierarchical level is usually per flow. Note that this level, like 
  *>    level 1, also supports transport functions. When an NSIS edge-to-edge 
  *>    multi-domain protocol is used, level 2 stretches beyond domain 
  *>    boundaries and is applied on all the edges of the domains that are 
  *>    included in the multidomain region. 
  *>     
  *>    The third hierarchical level ("level 3") includes a set of upper-
  *>    level signaling functions that are specific to particular signaling 
  *>    applications. Such functions could, for example, be security, policy, 
  *>    billing, etc. 
  *>     
  *>    As shown in Figure 10, the three hierarchical levels might be applied 
  *>    on different NSIS entities. 
  *>     
  *>    This three-level architecture for NSIS signaling can be provided by 
  *>    using: 
  *>     *) a single end-to-end NSIS protocol that supports all three 
  *>    hierarchical levels 
  *>     *) two independent NSIS protocols: Level 3 is supported by an end-
  *>    to-end NSIS protocol, and levels 1 and 2 are supported by another 
  *>    edge-to-edge NSIS protocol. 
  *>     
  *> 
  *>   
  *>  
  *>    |-----|   |-------|                           |-------|   |-----| 
  *>    |level|<--| level |<--------------------------| level |<->|level| 
  *>    |  3  |<--|   3   |                           |   3   |<->|  3  | 
  *>    |-----|   |-------|                           |-------|   |-----| 
  *>    |     |   |       |                           |       |   |     | 
  *>    |     |   |-------|                           |-------|   |     | 
  *>    |     |   | level |<------------------------->| level |   |     | 
  *>    |     |   |   2   |                           |   2   |   |     | 
  *>    |     |   |-------|                           |-------|   |     | 
  *>    |     |   |       |                           |       |   |     | 
  *>    |-----|   |       |   |
  *>               -------     -------|   |-------|   |-------|   |-----| 
  *>    |level|<->| level |<->| level |<->| level |<->| level |<->|level| 
  *>    |  1  |<->|   1   |<->|   1   |<->|   1   |<->|   1   |<->|  1  | 
  *>    |-----|   |-------|   |-------|   |-------|   |-------|   |-----| 
  *>      NI         NF          NF          NF          NF         NR 
  *>               (edge)     (interior)  (interior)   (edge) 
  *>                                       
  *>           Figure 10: Three level architecture for NSIS signaling 
  *>     
  *>    The components in the scenario are as follows: 
  *>     *) NI (NSIS Initiator): can be an end-host or a proxy and can 
  *>    process and use the "level 1" and "level 3" protocol components 
  *>     *) NR (NSIS Responder): can be an end-host or a proxy and can 
  *>    process and use the "level 1" and "level 3" protocol components 
  *>     *) NF (NSIS Forwarder) (edge): can be a Diffserv edge, MPLS edge, 
  *>    etc. It can process and use the "level 3", "level 2" and "level 1" 
  *>    protocol components. Usually, "level 2" provides an interworking 
  *>    between "level 1" and "level 3" protocol components. 
  *>     *) NF (interior): can be any router within a domain. It can process 
  *>    and use only the "level 1" protocol component. The "level 3" and 
  *>    "level 2" protocol components are not processed (used or checked). 
  *>     
  *>    The hierarchical level separation can be provided by supporting a 
  *>    hierarchical object structure. In other words, the NSIS protocol 
  *>    objects should be structured and positioned within the NSIS messages 
  *>    in a hierarchical way, i.e., first the "level 1" objects, then the 
  *>    "level 2" objects and finally the "level 3" objects. 
  *>  
  *> 8. Open Issues 
  *> 
  *>    The following issues are currently open points within the framework. 
  *>    They are summarized here to provide a single overview. 
  *>     
  *>     1. It is not clear which of the NI, NF and NR can modify or release 
  *>    existing reservations (this is essentially an authorisation issue). 
  *>    (Section 3.3.2.)  
  *>  
  *>     2. It is not clear whether NSIS entities relate to each other only 
  *>    locally (peer-peer) or whether longer distance, non-local 
  *>    interactions and state have to be managed and stored. (Section 
  *>    3.3.3.) 
  *>     
  *>     3. NSIS messages could be addressed either explicitly (to the 
  *>    neighboring peer) or implicitly, using the flow endpoint addresses. 
  *>    (Section 3.3.4.) 

If this is a question, the answer is "yes."  ;-)

  *>     
  *>     4. It is not clear where to draw the boundaries between the NTLP and 
  *>    NSIS signaling layer, and how to establish the extent to which the 
  *>    requirements of the diverse signaling applications considered for 
  *>    NSIS should influence NTLP functionality. (Section 3.3.5.) 
  *>     
  *>     5. If NSIS has explicit acknowledgement and notification messages, 
  *>    it is open whether they should relate to anything beyond the 
  *>    immediate peer relationship. (Section 3.3.6.) 
  *>     
  *>     6. To function as part of a complete system, the NSIS protocol may 
  *>    need to be supported by extensions to other protocols. These 
  *>    extensions are still to be identified. (Section 4.2.) 
  *>     
  *>     7. The NSIS protocol could be constructed on the services offered by 
  *>    lower layer protocols, but the dividing line between NSIS and these 
  *>    lower layers is not fixed. Use of standard lower layer protocols may 
  *>    be difficult if 'end-to-end addressing' (see section 3.3.4) is used. 
  *>    (Section 4.3.1.) 

It took me awhile to understand the last sentence; you should clarify it.

  *>     
  *>     8. It is commonly expected that a future resource signaling protocol 

I am glad to know that I am not "common". ;-)

  *>    would need to use abstract reservation identifiers. However, the 
  *>    precise properties needed of these identifiers are unclear, and 
  *>    enabling their secure use may be hard. (Sections 4.5.2 and 5.3.2.) 
  *>     
  *>     9. Use of some routing techniques (e.g. load sharing or QoS 
  *>    routing), even in remote parts of the network, could be incompatible 
  *>    with naive use of end-to-end addressing. (Sections 5.2.1 and 5.2.2.) 
  *>     

Well, YES!  So the conclusion, which should be pointed out clearly in
section 5.2, is that path-coupled signaling requires the *intelligent*
use of E2E addresing.

  *>     10. The correct flow identification semantics need to be defined in 
  *>    the case where mobility encapsulations might make it ambiguous which 
  *>    addresses to use. (Section 5.3.1.) 
  *>     
  *>     11. The interactions between mobility and resource signaling during 
  *>    path updating need to be further analyzed, especially from the point 
  *>    of view of combined overall latency. (Section 5.3.2 and 5.3.3.) 
  *>     
  *> 
  *> 
  *> 
...

Whew!  Hope some of this helps.

Bob Braden

----- End Included Message -----

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Thu, 14 Nov 2002 16:56:46 +0100

Bob, 

I noticed that this is the second time you refer to the interaction between routing & signaling by saying that there is "a LOT more to say"... could you please expand on what more you see is missing and be quite explicit about your points?  

I see several interactions possible between routing & signaling. For example, if you look into the advertisement needed for GQoS in IntServ, which forced additions to RSVP (one-pass with advertisement). An alternate design would be to rely on routing to carry the information (this information is very close to routing-information anyway) and only use signaling to install (resource) state in the routers. Routing could make use of additional information (such as, but I am not proposing in any way, the path characteristics collected in RSVP) when choosing paths. Hm, I guess this would be called non-traditional layer 3 routing...

Another interaction is what RSVP has chosen to do with the PATH messages, ie path state setup. This could be seen as a very non-traditional way of doing routing, since you effectively route-pin the RESV messages (at least as long as the path-state is there, right). So in effect, RSVP has two functions that could be generalised, path state setup and resource state setup. These are two distinct state manipulations, that could be described seperately. (ok, once again perhaps this leads off the topic, since it is a non-traditional way of layer 3 routing). Some have argued that route-pinning is required (at least beneficial) for load balancing algorithms in the network, since the problem to control stability has been claimed to be simpler. Old paths could be kept for already established flows, while new traverse the new path... ok, very untraditional L3 routing, but interesting thought.  

A third interaction that touch the previous is state manipulation and its relation to a path. If two routers that have a state that is shared between them (for example RESV-state), and it would be possible to forward packet between them and reach the end-station, if L3-routing changes the route for the flow (such that one end is not really on-path any longer) should you tear down the state? Yes is the obvious answer - however, not doing this causes less resource request and perhaps less denials for established reservations in the network. Not at all a trivial question, but changes L3 routing... once again off topic, I assume. 

So what interactions between _traditional_ L3-routing and signaling do you see? I am especially interested in your experiences from RSVP-development since you must have discussed these issues before. 

Best regards, 

Anders

---

From: Bob Braden <[email-masked]>
Date: Thu, 14 Nov 2002 20:51:07 GMT

*> Bob, 
  *> 
  *> I noticed that this is the second time you refer to the interaction between routing & signaling by saying that there is "a LOT more to say"... could you please expand on what more you see is missing and be quite explicit about your points?  
  *> 

I don't want to take time right now, but I can give you some references.
Unfortunately, I don't know of a single clear reference that covers the
subject, but there are a number of relevant fragments from which one
can piece together the entire story.  Here then are some relevant
references:

     Interdomain Multicast Routing Support for Integrated Services Networks 
     Zappala, D., Braden, B., Estrin, E., and S. Shenker, 
     Internet Draft, March 26, 1997.

	(This draft concentrates on the multicast problem because it is
	harder (;-)) but much of it is directly relevant to unicast routing.)

     RSRR: A Routing Interface For RSVP 
     Zappala, D., Kann, J., 
     Internet Draft, June 1998. 

     The Design of the RSVP Protocol, 
     Braden, R., Estrin, D., Berson, S., Herzog, S., and D. Zappala, 
     ISI Final Technical Report, July 1996.
	(The discussion on page 4.)

     The various IETF projects on QoS routing, e.g., RFC 2676.

Note: all of the above, except for the last, are available on the
RSVP web page (www.isi.edu/rsvp) under Publications.

I hope this will help answer your question.

Bob Braden