Subject: [NSIS] Some comments on draft-ietf-nsis-req-04.txt

From: Bob Braden <[email-masked]>
Date: Sun, 20 Oct 2002 19:53:53 -0700 (PDT)

Friends,

Recently John Loughney asked me to review the requirements document,
and I have finally found a little time.  I am far behind in reading
NSIS messages, but I think I have seen that there is some intent to
issue a WG last call on this document.  (If I am wrong, I apologize).

I am afraid that I think that this document is not ready for a last
call.  Besides many issues of content, its editorial form is far from
satisfactory.  It would certainly not be acceptable at this point for
publication as an RFC, which is presumably the eventual intent of a
last call; there are too many confusing, awkward, and/or
grammatically incorrect sentences, for one thing.

I hope the following comments will be useful.  I am aware that they are
hastily composed and undoubtedly could benefit from further
consideration.   I regret mixing together problems at all levels from
architectural issues to English composition to editorial nits.
However, I believe that the majority of my comments reflect problems
that need some kind of fix.  These comments are incomplete, but
fixing/clarifying the issues marked will be a good step forward.

Before I start, let me make a few general comments.

1. I believe that the ADs sent the WG on a Mission Impossible by
	asking for a requirements document before a framework
	document.  It really is not possible to write a useful
	requirements document except within the context of an overall
	signaling architecture, which I believe is what the framework
	document aspires to provide.  Details aside, this is not a bad
	job of reaching an intrinsically impossible goal.

2. I believe that NSIS will be successful (only) if its product turns
	out to handle signaling applications that we have not thought
	of yet.  It is not enough in the Internet to handle today's
	problems; given the rapidly shifting technology, we can
	survive only if we build protocol structures of sufficient
	generality to handle tomorrow's problems.

3. In this light, I am concerned with the WG's focusing exclusively on
	the QoS problem (or the many QoS problems, to be more precise.)
	A major lesson from RSVP is that we need to think more generally.

Here goes.

  *> 
  *> 
  *>    Network Working Group                            M. Brunner (Editor) 
  *>    Internet Draft                                                   NEC 
  *>    Category: Informational                                  August 2002 
  *>                                                                         
  *>  
  *>  
  *>                    Requirements for Signaling Protocols 

		"Requirements for Internet Signaling Protocols"

  *>                        <draft-ietf-nsis-req-04.txt> 
  *>  

  *> Abstract 
  *>     
  *>    This document defines requirements for signaling across different 
  *>    network environments, where different network environments across 
  *>    administrative and technology domains.

Huh?

  *>    Signaling is mainly though 

		"The primary focus of this memo is on signaling for QoS;
		however, there are many other potential applications of
		Internet signaling.

  *>    for QoS such as [1], however in recent year several other 

No references in Abstracts.

  *>    applications of signaling have been defined such as signaling for 
  *>    MPLS label distribution [2]. To achieve wide applicability of the 
  *>    requirements, the starting point is a diverse set of scenarios/use 
  *>    cases concerning various types of networks and application 
  *>    interactions.  We also provide an outline structure for the problem, 

(Actually it is not very diverse set, but I leave that for later.)

  *>    including related terminology. Taken with the scenarios, this allows 
  *>    us to focus more precisely on which parts of the overall problem 
  *>    need to be solved. We present the assumptions and the aspects not 
  *>    considered within scope before listing the requirements grouped 
  *>    according to areas such as architecture and design goals, signaling 
  *>    flows, layering, performance, flexibility, security, and mobility.  

The Abstract is a little mungey, composition-wise.

  *>     
  *>    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. 
  *>     

Not in the Abstract!

  *>    Brunner (Editor)         Informational                    [Page 1] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *> Table of Contents 
  *>     
  *>    Status of this Memo................................................1 
  *>    Abstract...........................................................1 
  *>    Table of Contents..................................................2 
  *>    1  Introduction...................................................3 
  *>    2  Terminology....................................................4 
  *>    3  Problem Statement and Scope....................................6 
  *>    4  Assumptions and Exclusions.....................................8 
  *>    4.1  Assumptions and Non-Assumptions..............................8 
  *>    4.2  Exclusions...................................................9 
  *>    5  Requirements..................................................11 
  *>    5.1  Architecture and Design Goals...............................11 

Too fine-grained a TOC!

  *>    5.1.1 MUST be applicable for different technologies...............11 
  *>    5.1.2 Resource availability information on request................12 
  *>    5.1.3 NSIS MUST be designed modular...............................12 
  *>    5.1.4 NSIS MUST decouple protocol and information.................12 
  *>    5.1.5 NSIS MUST reuse existing QoS provisioning...................12 
  *>    5.1.6 Independence of signaling and provisioning paradigm.........12 
  *>    5.1.7 Application independence....................................13 
  *>    5.2  Signaling Flows.............................................13 
  *>    5.2.1 Free placement of NSIS Initiator, Forwarder, Responder......13 
  *>    5.2.2 No constraint of the signaling and NSIS Forwarders to be in 
  *>    the data path.....................................................13 
  *>    5.2.3 Concealment of topology and technology information..........14 
  *>    5.2.4 Transparency of signaling to network........................14 
  *>    5.3  Additional information beyond signaling for a service.......14 
  *>    5.3.1 Explicit release of resources...............................14 
  *>    5.3.2 Possibility for automatic release of resources after failure15 
  *>    5.3.3 Notifications sent upstream.................................15 
  *>    5.3.4 Feedback about success of service request...................16 
  *>    5.3.5 Local information exchange..................................16 
  *>    5.4  Control Information.........................................16 
  *>    5.4.1 Mutability information on parameters........................16 
  *>    5.4.2 Possibility to add and remove local domain information......17 
  *>    5.4.3 Independence of reservation identifier......................17 
  *>    5.4.4 Seamless modification of already reserved resources.........17 
  *>    5.4.5 Grouping of signaling for several microflows................17 
  *>    5.5  Performance.................................................17 
  *>    5.5.1 Scalability.................................................18 
  *>    5.5.2 Low latency in setup........................................18 
  *>    5.5.3 Allow for low bandwidth consumption for signaling protocol..18 
  *>    5.5.4 Ability to constrain load on devices........................18 
  *>    5.5.5 Highest possible network utilization........................19 
  *>    5.6  Flexibility.................................................19 
  *>    5.6.1 Flow aggregation............................................19 
  *>    5.6.2 Flexibility in the placement of the NSIS Initiator..........19 
  *>    5.6.3 Flexibility in the initiation of re-negotiation.............19 
  *>    5.6.4 Uni / bi-directional reservation............................19 
  *>    5.7  Security....................................................20 
  *>    5.7.1 Authentication of signaling requests........................20 
  *>    5.7.2 Resource Authorization......................................20 
  *>    5.7.3 Integrity protection........................................20 
  *>    5.7.4 Replay protection...........................................20 
  *>      
  *>    Brunner (Editor)         Informational                    [Page 2] 
...

  *>     
  *> 1  Introduction 
  *>     

Should start by defining "signaling" (?)

  *>    This document defines requirements for signaling across different

                             " requirements for level 3 signaling" 

  *>    network environments. It does not list any problems of existing 
  *>    signaling protocols such as RSVP [1].  

The last hardly needs to be said; the reader is unlikely to expect that it
would.

  *>     
  *>    In order to derive requirements for signaling it is necessary to 
  *>    first have a clear idea of the scope within which they are 
  *>    applicable.  
  *>     
  *>    We describe a set of QoS signaling scenarios and use cases in the 
                                                     XXX XXX XXXXX

  *>    Appendix of that document. These scenarios derive from a variety of 
                    this?

  *>    backgrounds, and help obtain a clearer picture of what is in or out 
  *>    of scope of the NSIS work. They illustrate the problem of QoS 

You jumped without explanation into QoS.

  *>    signaling from various perspectives (end-system, access network, 
  *>    core network) and for various areas (fixed line, mobile, wireless 
  *>    environments).  
  *>     
  *> 
  *>      
  *>    Brunner (Editor)         Informational                    [Page 3] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    Based on these scenarios, we are able to define the signaling 
  *>    problem on a more abstract level. In Section 3, we thus present a 
  *>    simple conceptual model of the signaling problem. Additionally, we 
  *>    describe the entities involved in signaling and typical signaling 
  *>    paths. In Section 4 we list assumptions and exclusions.  

Using the 1st person plural here detracts.

  *>     
  *>    The model of Section 3 allows deriving requirements from the 
  *>    scenarios presented in the appendix in a coherent and consistent 
  *>    manner. Requirements are grouped according to areas such as 
  *>    Architecture and design goals, Signaling Flows, Layering, 
  *>    Performance, Flexibility, Security and Mobility. 
  *>     
  *>    QoS is a pretty large field with a lot of interaction with other 
  *>    protocols, mechanisms, applications etc.  However, it is not the 
  *>    only field where signaling is used in the Internet. Even if this 
  *>    requirement documents mainly used QoS as the sample application 
  *>    other application should be possible. 

This is an explanation of scope that needs to be more explicit and
perhaps earlier.

  *>  
  *>    It is clear that the subject of QoS is uniquely complex and any 
        XX XX XXXXX XXXX T                     *uniquely*?     ,

  *>    investigation could potentially have a very broad scope - so broad 
  *>    that it is a challenge to focus work on an area, which could lead to 
  *>    a concrete and useful result. This is our motivation for considering 
  *>    a set of use cases, which map out the domain of application that we 
  *>    want to address. It is also the motivation for defining a problem 
  *>    structure, which allows us to state the boundaries of what types of 
  *>    functionality to consider, and to list background assumptions.  
  *>     
  *>    There are several areas of the requirements related to networking 
  *>    aspects which are incomplete, for example, interaction with host and 
  *>    site multi-homing, use of anycast services, and so on. These issues 
  *>    should be considered in any future analysis work. 
  *>     
  *> 2  Terminology 
  *>     
  *>    In the area of Quality of Service (QoS) it is quite difficult and an 
  *>    exercise for its own to define terminology. Nevertheless, we tried 
  *>    to list the most often used terms in the draft and tried to explain 
  *>    them. However, don't be to religious about it, they are not meant to 
  *>    prescribe any thing in the draft. 

But you do prescribe .. to much, in my view.

I cannot resist a polemic about bad protocol documentation.  There is
an increasingly common way to produce totally opaque protocol
specifications: instead of a clear, step-by-step explanation of the
architectural model, we put in a Terminology section.  The naive
reader who expects to be able to just read and understand the material, is
forced instead into decoding the terms, skipping back and forth to find
the definition of the definition of the definition of the definition...
It replaces prose by a logical puzzle.

  *>  
  *>    NSIS Domain (ND) - Administrative domain where an NSIS protocol 
                           An administrative domain in which an ...

  *>    signals for a resource or set of resources.  

You are falling right into the QoS-exclusive trap.  How about:
	
		NSIS Domain - An administrative domain in which an NSIS
				protocol passes some control information.

  *>         
  *>    NSIS Entity (NE) - the function within a node, which implements an 
  *>    NSIS protocol.

			- the function within a node that implements an

We are starting to fall into the habit of calling the signaling protocol
NSIS.  That does not make any sense to me.  NSIS is the name of the WG,
but it makes little sense as the name of a protocol.  We could have
called BGP "Next Step in Routing" (NSIR), but I don't think that would
have been useful.

What name should we use?  Beats me, but we will need a name.  Or maybe
a bunch of names, if you believe all of the generality later in this
document.

  *>         
  *>    NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR, 

Expand NI and NR here, since they have not yet been defined.

  *>    which may interact with local resource management function (RMF) for 

Again this is QoS specific... need it more general.

  *>    this purpose. NSIS Forwarder also propagates NSIS signaling further 
  *>    through the network. It is responsible for interpreting the 
  *>    signaling carrying the user parameters, optionally inserting or 

User parameters -- defined? The same as "control information" used later?

  *>    modifying the parameters according to domain network management 
  *>    policy. 
  *>         
  *>      
  *>    Brunner (Editor)         Informational                    [Page 4] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for 
  *>    a network resource based on user or application requirements. This 
  *>    can be located in the end system, but may reside elsewhere in 
  *>    network. 
  *>         
  *>    NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and 
  *>    can optionally interact with applications as well.  
  *>      

These definitions are confusing.  RSVP initiates signaling from both
ends, so by this definition RSVP has an NI and an NR in both sender and
receiver (and in fact, I think that's right.) But in several places
later in the document this gets confused with which way the
reservation/state setup flows.

There may be a deep issue here.  The WG has a tendency to think only
about a simplistic view of signaling as a one-way process.  But RSVP
showed that some signaling may be essentially two-way, and the protocol
needs to be able to handle that when it *is* required.

  *>    Resource Management Function (RMF) - an abstract concept, 
  *>    representing the management of resources in a domain or a node.   
  *>  
  *>    Egress point: the router via which a path exits a domain/subdomain. 
  *>     
  *>    End Host: the end system or host, for whose flows QoS is being 
  *>    requested and provisioned. 

(As worded, precludes edge-to-edge signaling)

  *>     
  *>    End-to-End QoS: the QoS delivered by the network between two 
  *>    communicating end hosts.  End-to-end QoS co-ordinates and enforces 
  *>    predefined traffic management policies across multiple network 

Predefined??  What doe this sentence mean?

  *>    entities and administrative domains. 
  *>     
  *>    Edge-to-edge QoS: QoS within an administrative domain that connects 
  *>    to other networks rather than hosts or end systems.  
  *>     

Define End-to-Edge signaling, which is used later?

  *>    Flow: a traffic stream (sequence of IP packets between two end 
  *>    systems) for which a specific level of QoS is to be provided. The 
  *>    flow can be unicast (uni- or bi-directional) or multicast. 
  *>     
  *>    Higher Layers: the higher layer (transport protocol and application) 
  *>    functions that request QoS from the network layer. The request might 
  *>    be a trigger generated within the end system, or the trigger might 
  *>    be provided by some entity within the network (e.g. application 
  *>    proxy or policy server). 

I suggest that using "higher layer", already overloaded, for the
present purpose is a bad idea.

This use of the word "trigger" is related to RSVP's usage, but it
is not entirely obvious.

  *>     
  *>    Indication: feedback from QoS provisioning to indicate the current 
  *>    QoS being provided to a flow or aggregate, and whether any 
  *>    violations have been detected by the QoS technology is being used 
  *>    within the local domain/subdomain. 
  *>     
  *>    Ingress point: the router via which a path enters a 
  *>    domain/subdomain. 
  *>     
  *>    Path: the route across the networks taken by a flow or aggregate, 
  *>    i.e. which domains/subdomains it passes through and the 
  *>    egress/ingress points for each. 

I don't accept this definition; for one thing, it precludes RSVP-style
hop/hop signaling.  You have to work harder here.

  *>     
  *>    Path segment: the segment of a path within a single 
  *>    domain/subdomain. 
  *>     
  *>    Control Information: the information the governs for instance the 
                                             that
  *>    QoS treatment to be applied to a flow or aggregate, including the 
  *>    service class, flow administration, and any associated security or 
  *>    accounting information. 
  *>  

Security/accounting == policy, as the IETF defines it.

  *>      
  *>    Brunner (Editor)         Informational                    [Page 5] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    QoS Provisioning: the act of actually allocating resources to a flow 
  *>    or aggregate of flows, may include mechanisms such as LSP initiation 
  *>    for MPLS, packet scheduler configuration within a router, and so on. 
  *>    The mechanisms depend on the overall QoS technology being used 
  *>    within the domain. 

[How] is QoS provisioning different from resource allocation???

  *>  
  *>    Subdomain: a network within an administrative domain using a uniform 
  *>    technology, e.g., a single QoS provisioning function to provision 
  *>    resources. 
  *>     
  *>    QoS Technology: a generic term for a set of protocols, standards and 
  *>    mechanisms that can be used within a QoS domain/subdomain to manage 
  *>    the QoS provided to flows or aggregates that traverse the domain. 
  *>    Examples might include MPLS, DiffServ, and so on. A QoS technology 
  *>    is associated with certain QoS provisioning techniques. 
  *>  
  *>    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. 

Which rules or policy criteria are used to grant access to buffers?

  *>     
  *>    Resource Allocation: part of a resource that has been dedicated for 
  *>    the use of a particular traffic type for a period of time through 
  *>    the application of policies. 

"traffic type" means???  Maybe you mean something more like a flow?

  *>  
  *>    Sender-initiated signaling protocol: A sender-initiated signaling 
  *>    protocol is a protocol where the NI initiates the signaling on 
  *>    behalf of the sender of the data. What this means is that admission 
  *>    control and resource allocation functions are processed from the 
  *>    data sender towards the data receiver. However, the triggering 
  *>    instance is not specified.  

I have no idea what the last sentence meant.

Except that the definition is QoS-specific, the 2nd sentence here makes
some sense. But the use of NI here confuses the definition, as in the
RSVP case.

  *>     
  *>    Receiver-initiated signaling protocol: A receiver-initiated 
  *>    protocol, (see e.g., RSVP [1]) is a protocol where the NSIS 
  *>    Responder on behalf of the receiver of the user data initiates the 
  *>    reservations. What this means is that admission control and resource 
  *>    allocation functions are processed from the data receiver back 
  *>    towards the data sender. However, the triggering instance is not 
  *>    specified. 
  *>  
  *> 3  Problem Statement and Scope 
  *>     
  *>    We provide in the following a preliminary architectural picture as a 
  *>    basis for discussion. We will refer to it in the following 
  *>    requirement section. 

This architectural picture, which seems to be an instance of Lixia Zhang's hierarchical model for resource
reservation, would seem to belong in the framework document.  It is,
I think, QoS-specific, and it may be controversial.

Let me suggest an alternative: at this point in the requirements
insert a general definition of the two-level model and a discussion
of layering issues.  I suppose some of the material below could then
be included as an example of one way to structure a QoS signaling
function.

  *>     
  *>    A set of issues and problems to be solved has been given at a top 
  *>    level by the use cases/scenarios of the appendix. However, the 
  *>    problem of QoS has an extremely wide scope and there is a great deal 
  *>    of work already done to provide different components of the 
  *>    solution, such as QoS technologies for example. A basic goal should 
  *>    be to re-use these wherever possible, and to focus requirements work 
  *>    at an early stage on those areas where a new solution is needed 
  *> 
  *>      
  *>    Brunner (Editor)         Informational                    [Page 6] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    (e.g. an especially simple one). We also try to avoid defining 
  *>    requirements related to internal implementation aspects. 
  *>     
  *>    In this section, we present a simple conceptual model of the overall 
  *>    problem in order to identify the applicability to NSIS of 
  *>    requirements derived from the use cases, and to clarify the scope of 
  *>    the work, including any open issues. This model also identifies 
  *>    further sources of requirements from external interactions with 
  *>    other parts of an overall solution, clarifies the terminology used, 
  *>    and allows the statement of design goals about the nature of the 
  *>    solution (see section 5). 
  *>     
  *>    Note that this model is intended not to constrain the technical 
  *>    approach taken subsequently, simply to allow concrete phrasing of 
  *>    requirements (e.g. requirements about placement of the NSIS 
  *>    Initiator, or ability to 'drive' particular QoS technologies.) 
  *>     
  *>    Roughly, the scope of NSIS is assumed to be the interaction between 
  *>    the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder 
  *>    including a protocol to carry the information, and the 
  *>    syntax/semantics of the information that is exchanged. Further 
  *>    statements on assumptions/exclusions are given in the next Section. 
  *>     
  *>    The main elements are: 
  *>     
  *>    1. Something that starts the request for resources, the NSIS  
                          triggers a?
  *>    Initiator.  
  *>     
  *>    This might be in the end system or within some other part of the 
  *>    network. The distinguishing feature of the NSIS Initiator is that it 
  *>    acts on triggers coming (directly or indirectly) from the higher
                requests?
  *>    layers in the end systems. It needs to map the resources requested 
Not necessarily an end system.

  *>    by them, and also provides feedback information to the higher 
  *>    layers, which might be used by transport layer rate management or 
  *>    adaptive applications. 
  *>     
  *>    2. Something that assists in managing resources further along the 
  *>    path, the NSIS Forwarder.  
  *>     
  *>    The NSIS Forwarder does not interact with higher layers, but 
  *>    interacts with the NSIS Initiator and possibly more NSIS Forwarders 
  *>    on the path, edge-to-edge or possibly end-to-end. 
  *>     
  *>    3. The NSIS Initiator and NSIS Forwarder(s) interact with each 
  *>    other, path segment by path segment. This interaction involves the 
  *>    exchange of data (resources control information) over some signaling 
  *>    protocol. 
  *>     
  *>    4. The path segment traverses an underlying network covering one or 
  *>    more IP hops. The underlying network uses some local QoS technology. 
  *>    This QoS technology has to be provisioned appropriately for the 
  *>    service requested. An NSIS Forwarder maps service-specific 
  *>    information to technology-related QoS parameters and receiving 
  *>    indications about success or failure in response. 

Maybe this discussion could be clarified by a diagram?

Use your term RMF here?

  *>      
  *>    Brunner (Editor)         Informational                    [Page 7] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>     
  *>    Now concentrating more on the overall end to end (multiple domain) 
  *>    aspects, in particular: 
  *>     
  *>    1. The NSIS Initiator need not be located at an end system, and the 
  *>    NSIS Forwarders are not assumed to be located on the flow's data 
  *>    path. However, they must be able to identify the ingress and egress 
  *>    points for the flow path as it traverses the domain/subdomain. Any 
  *>    signaling protocol must be able to find the appropriate NSIS 
  *>    Forwarder and carry this ingress/egress point information. 
  *>     
  *>    2. We see the network at the level of domains/subdomains rather than 
  *>    individual routers (except in the special case that the domain 
  *>    contains one link). Domains are assumed to be administrative 
  *>    entities, so security requirements apply to the signaling between 
  *>    them.  
  *>     
  *>    3. Any domain may contain Resource Management Function (e.g. to do 
  *>    with traffic engineering, admission control, policy and so on). 
  *>    These are assumed to interact with the NSIS Initiator and 
  *>    Controllers (and end systems) using standard mechanisms. 
  *>     
  *>    4. The placement of the NSIS Initiators and NSIS Forwarders is not 
  *>    fixed.  
  *>  

Yes!  I could never figure out why people made such a big deal out of
this.  The RSVP protocol really does not care whether signaling is
initiated; it would have been a simple matter of word-smithing to
extend RSVP to cover end-to-edge, edge-to-edge, etc.  We get knee-deep
in bogus concerns.

  *> 4  Assumptions and Exclusions 
  *>     
  *> 4.1 Assumptions and Non-Assumptions 
  *>     
  *>    1. The NSIS signaling could run end to end, end to edge, or edge to 
  *>    edge, or network-to-network ((between providers), depending on what 

Yes, of course.

  *>    point in the network acts as the initiator, and how far towards the 
  *>    other end of the network the signaling propagates. Although the 
  *>    figures show NSIS Forwarders at a very limited number of locations 
  *>    in the network (e.g. at domain or subdomain borders, or even 
  *>    controlling a complete domain), this is only one possible case. In 
  *>    general, we could expect NSIS Forwarders to become more 'dense' 
  *>    towards the edges of the network, but this is not a requirement. An 
  *>    over-provisioned domain might contain no NSIS Forwarders at all (and 
  *>    be NSIS transparent); at the other extreme, NSIS Forwarders might be 
  *>    placed at every router. In the latter case, QoS provisioning can be 
  *>    carried out in a local implementation-dependent way without further 
  *>    signaling, whereas in the case of remote NSIS Forwarders, a 
  *>    provisioning protocol might be needed to control the routers along 
  *>    the path. This provisioning protocol is then independent of the end-
  *>    to-end NSIS signaling.  

The last sentence is confusing.

  *>     
  *>    2. We do not consider 'pure' end-to-end signaling that is not 
  *>    interpreted anywhere within the network. Such signaling is an 
  *>    application-layer issue and IETF protocols such as SIP etc. can be 
  *>    used. 
  *>     
  *>    3. Where the signaling does cover several NSIS domains or 
                 XXX           crossesXXX
  *>    subdomains, we do not exclude that different signaling protocols are 
  *>      
  *>    Brunner (Editor)         Informational                    [Page 8] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    used in each path segment. We only place requirements on the 
  *>    universality of the control information that is being transported. 
  *>    (The goals here would be to allow the use of signaling protocols, 
  *>    which are matched to the characteristics of the portion of the 
  *>    network being traversed.) Note that the outcome of NSIS work might 
  *>    result in various protocols or various flavors of the same protocol. 
  *>    This implies the need for the translation of information into domain 
  *>    specific format as well. 
  *>     
  *>    4. We assume that the service definitions a NSIS Initiator can ask 
  *>    for are known in advance of the signaling protocol running. Service 
  *>    definition includes QoS parameters, lifetime of QoS guarantee etc., 
  *>    or any other service-specific parameters. 
  *>     
  *>    There are many ways service requesters get to know about it. There 
  *>    might be standardized services, the definition can be negotiated 
  *>    together with a contract, the service definition is published at a 
  *>    Web page, etc.  
  *>     
  *>    5. We assume that there are means for the discovery of NSIS entities 
           There must be ... 

  *>    in order to know the signaling peers (solutions include static 
  *>    configuration, automatically discovered, or implicitly runs over the 
  *>    right nodes, etc.) The discovery of the NSIS entities has security 
  *>    implications that need to be addressed properly. These implications 
  *>    largely depend on the chosen protocol. For some security mechanisms 
  *>    (i.e. Kerberos, pre-shared secret) it is required to know the 
  *>    identity of the other entity. Hence the discovery mechanism may 
  *>    provide means to learn this identity, which is then later used to 
  *>    retrieve the required keys and parameters.  
  *>     
  *>    6. NSIS assumes to operate with networks using standard ("normal") 
  *>    L3 routing. Where "normal" is not specified more exactly on purpose. 
  *>     
  *> 4.2 Exclusions 
  *>     

Are you excluding requirements, or excluding mechanisms?  If the latter,
this section does not seem to belong in a requirements document.
If the former, rephase each in terms of requirements.

  *>    1. Development of specific mechanisms and algorithms for application 
  *>    and transport layer adaptation are not considered, nor are the 
  *>    protocols that would support it. 
  *>     
  *>    2. Specific mechanisms (APIs and so on) for interaction between 
  *>    transport/applications and the network layer are not considered, 
  *>    except to clarify the requirements on the negotiation capabilities 
  *>    and information semantics that would be needed of the signaling 
  *>    protocol. The same applies to application adaptation mechanisms. 
  *>     
  *>    3. Specific mechanisms for QoS provisioning within a 
  *>    domain/subdomain are not considered. However, NSIS can be used for 
  *>    signaling within a domain/subdomain performing QoS provisioning. It 
  *>    should be possible to exploit these mechanisms optimally within the 
  *>    end-to-end context. Consideration of how to do this might generate 
  *>    new requirements for NSIS however. For example, the information 
  *>    needed by a NSIS Forwarder to manage a radio subnetwork needs to be 
  *>    provided by the NSIS solution. 
  *>     
  *>      
  *>    Brunner (Editor)         Informational                    [Page 9] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    4. Specific mechanisms (APIs and so on) for interaction between the 
  *>    network layer and underlying QoS provisioning mechanisms are not 
  *>    considered.  
  *>     
  *>    5. Interaction with resource management capabilities is not 
  *>    considered. Standard protocols should be used for this (e.g. COPS). 
  *>    This may imply requirements for the sort of information that should 
  *>    be exchanged between the NSIS entities. 
  *>  
  *>    6. Security implications related to multicasting are outside the 
  *>    scope of the signaling protocol.  
  *>  
  *>    7. Protection of non-signaling messages is outside the scope of the 
  *>    protocol  
  *>     
  *>    The protection of non-signaling messages (including data traffic 
  *>    following a reservation) is not directly considered by a signaling 
  *>    protocol. The protection of data messages transmitted along the 
  *>    provisioned path is outside the scope of a signaling protocol. 
  *>    Regarding data traffic there is an interaction with accounting 
  *>    (metering) and edge routers might require packets to be integrity 
  *>    protected to be able to securely assign incoming data traffic to a 
  *>    particular user.  
  *>  
  *>    Additionally there might be an interaction with IPSec protected 
  *>    traffic experiencing QoS treatment and the established state created 
  *>    due to signaling. One example of such an interaction is the different 
  *>    flow identification with and without IPSec protection.  
  *>     
  *>    Many security properties are likely to be application specific and 
  *>    may be provided by the corresponding application layer protocol.  
  *>     
  *>    8. Service definitions and in particular QoS classes are out of 
  *>    scope. Together with the service definition any definition of 
  *>    service specific parameters are not considered in this draft. Only 
  *>    the base NSIS signaling protocol for transporting the service 
  *>    information are handled. 
  *>     
  *>    9. Similarly, specific methods, protocols, and ways to express 
  *>    QoS/service information in the Application/Session level are not 
  *>    considered (e.g., SDP, SIP, RTSP, etc.).  
  *>     
  *>    10. The specification of any extensions needed to signal information 
  *>    via application level protocols (e.g. SDP), and the mapping on NSIS 
  *>    information are considered outside of the scope of NSIS working 
  *>    group, as this work is in the direct scope of other IETF working 
  *>    groups (e.g. MMUSIC). 
  *>     
  *>    11. Handoff decision and trigger sources: An NSIS protocol is not 
  *>    used to trigger handoffs in mobile IP, nor is it used to decide 

Why not, and who says?

  *>    whether to handoff or not. As soon as or in some situation even 
  *>    before a handoff happened, an NSIS protocol might be used for 
  *>    signaling for QoS again. However, NSIS MUST interwork with several 
  *>    protocols for mobility management. 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 10] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>     
  *>    12. QoS monitoring is out of scope. It is heavily dependent on the 
  *>    type of the application and or transport service, and in what 
  *>    scenario it is used. 
  *>  

Sounds like a serious omission to me.

  *> 5  Requirements 
  *>     
  *>    This section defines more detailed requirements for a signaling 
  *>    solution, derived from consideration of the use cases/scenarios 
  *>    described in the appendix, and respecting the framework, scoping 
  *>    assumptions, and terminology considered earlier. The requirements 
  *>    are in subsections, grouped roughly according to general technical 
  *>    aspects: architecture and design goals, topology issues, parameters, 
  *>    performance, security, information, and flexibility. 
  *>     
  *>    Two general (and potentially contradictory) goals for the solution 
  *>    are that it should be applicable in a very wide range of scenarios, 
  *>    and at the same time lightweight in implementation complexity and 
  *>    resource requirements in nodes. One approach to this is that the 
  *>    solution could deal with certain requirements via modular components 
  *>    or capabilities, which are optional to implement in individual 
  *>    nodes.  
  *>     
  *>    Some of the requirements are technically contradictory. Depending on 
  *>    the scenarios a solution applies to, one or the other requirement is 
  *>    applicable.  
  *>     
  *>    In order to prioritize the various requirements we define different 
  *>    'parts of the network'. In the different parts of the network a 
  *>    particular requirement might have a different priority.  
  *>     
  *>    The parts of the networks we differentiate are the host-to-first 
  *>    router, the access network, and the core network. The host to first 
  *>    router part includes all the layer 2 technologies to access to the 
  *>    Internet. In many cases, there is an application and/or user running 
  *>    on the host initiating signaling. The access network can be 
  *>    characterized by low capacity links, medium speed IP processing 
  *>    capabilities, and it might consist of a complete layer 2 network as 
  *>    well. The core network characteristics include high-speed forwarding 
  *>    capacities and inter-domain issues. All of them are not strictly 
  *>    defined and should not be regarded as that, but should give a 

Then maybe better not to include something so mushy?

  *>    feeling about where in the network we have different requirements 
  *>    concerning signaling. 
  *>     
  *> 5.1 Architecture and Design Goals 
  *>     
  *>    This section contains requirements related to desirable overall 
  *>    characteristics of a solution, e.g. enabling flexibility, or 
  *>    independence of parts of the framework. 
  *>     
  *> 5.1.1 MUST be applicable for different technologies. 
  *>      
  *>    The signaling protocol MUST work with various QoS technologies as 
  *>    well as other technologies needing signaling. The information 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 11] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    exchanged over the signaling protocol must be in such detail and 
  *>    quantity that it is useful for various technologies.  
  *>     
  *> 5.1.2 Resource availability information on request  
  *>  
  *>    In some scenarios, e.g., the mobile terminal scenario, it is 
  *>    required to query, whether resources are available, without 
  *>    performing a reservation on the resource. One solution might be a 
  *>    feedback mechanism based on which a QoS inferred handover can take 
  *>    place. So NSIS SHOULD provide a mechanism to check whether resources 
  *>    are available without performing a reservation 
  *>     
  *> 5.1.3 NSIS MUST be designed modular  
  *>  
  *>    A modular design allows for more lightweight implementations, if 
  *>    fewer features are needed. Mutually exclusive solutions are 
  *>    supported. Examples for modularity: 

Modularity is good, but the following examples bear no relationship to
MY idea of "modularity"?!  See two-level signaling model for modularity
discussion.  Also, many of these occur later as requirements.

  *>     
  *>    - Work over any kind of network (narrowband versus broadband, error-
  *>    prone versus reliable, ...). This implies low bandwidth signaling 
  *>    and redundant information MUST be supported if necessary.  
  *>     
  *>    - Uni- and bi-directional reservations are possible 
  *>     
  *>    - Extensible in the future with different add-ons for certain 
  *>    environments or scenarios  
  *>     
  *>    - Protocol layering, where appropriate. This means NSIS MUST provide 
  *>    a base protocol, which can be adapted to different environments. 
  *>     
  *> 5.1.4 NSIS MUST decouple protocol and information

Maybe there is a more elegant way to phrase this?
 
  *>  
  *>    The signaling protocol MUST be clearly separated from the control 
  *>    information being transported. This provides for the independent 
  *>    development of these two aspects of the solution, and allows for 
  *>    this control information to be carried within other protocols, 
  *>    including application layer ones, existing ones or those being 
  *>    developed in the future. The gained flexibility in the information 
  *>    transported allows for the applicability of the same protocol in 
  *>    various scenarios.  
  *>     
  *>    However, note that the information carried needs to be the 
  *>    standardized; otherwise interoperability is difficult to achieve. 
  *>  
  *> 5.1.5 NSIS MUST reuse existing QoS provisioning 
  *>  
  *>    Reuse existing functions and protocols for QoS provisioning within a 
  *>    domain/subdomain unchanged. (Motivation: 'Don't re-invent the 
  *>    wheel'.) 
  *>     
  *> 5.1.6 Independence of signaling and provisioning paradigm 
  *>  
  *>    The signaling MUST be independent of the paradigm and mechanism of 
  *>    provisioning. E.g., in the case of signaling for QoS, the 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 12] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    independence of the signaling protocol from the QoS provisioning 
  *>    allows for using the NSIS protocol together with various QoS 
  *>    technologies in various scenarios. 
  *>  
  *> 5.1.7 Application independence 
  *>     
  *>    The signaling protocol MUST be independent of the application. The 
  *>    control information SHOULD be application independent, because we 
  *>    look into network level signaling.  
  *>     
  *>    The requirement relates to the way the signaling interacts with 
  *>    upper layer functions (users, applications, and QoS administration), 
  *>    and lower layer QoS technologies. 
  *>     
  *>    Opaque application information MAY get transported in the signaling 
  *>    message, without being handled in the network. Development and 

Really?? I suggest you want to think twice about that, and justify it.
It certainly mungs the Internet architecture, so yoiu want to be
sure there is a strong justification.

  *>    deployment of new applications SHOULD be possible without impacting 
  *>    the network infrastructure.  

  *>     
  *> 5.2 Signaling Flows 
  *>     
  *>    This section contains requirements related to the possible signaling 
  *>    flows that should be supported, e.g. over what parts of the flow 
  *>    path, between what entities (end-systems, routers, middle boxes, 
  *>    management systems), in which direction.  
  *>  
  *> 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder 
  *>     
  *>    The protocol MUST work in various scenarios such as host-to-network-
                          be applicable to various...

  *>    to-host, edge-to-edge, (e.g., just within one providers domain), 
  *>    user-to-network (from end system into the network, ending, e.g., at 
  *>    the entry to the network and vice versa), and network-to-network 
  *>    (e.g., between providers).  
  *>     
  *>    Placing the NSIS Forwarder and NSIS Initiator functions at different 
  *>    locations allows for various scenarios to work with the same 
  *>    protocol. 
  *>     
  *> 5.2.2 No constraint of the signaling and NSIS Forwarders to be in the 
  *>      data path. 
  *>     
  *>    There is a set of scenarios, where signaling is not on the data 
  *>    path. The NSIS Forwarder being in the data path is one extreme case 
  *>    and useful in many cases. Therefore the case of having NSIS entities 
  *>    on the data path only MUST be allowed. 
  *>     
  *>    There are going to be cases where a centralized entity will take a 
  *>    decision about service requests. In this case, there is no need to 
  *>    have the data follow the signaling path.  
  *>     
  *>    There are going to be cases without a centralized entity managing 
  *>    resources and the signaling will be used as a tool for resource 
  *>    management. For various reasons (such as efficient use of expensive 
  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 13] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    bandwidth), one will want to have fine-grained, fast, and very 
  *>    dynamic control of the resources in the network. 
  *>     
  *>    There are going to be cases where there will be neither signaling 
  *>    nor a centralized entity (over-provisioning). Nothing has to be done 
  *>    anyway. 
  *>     
  *>    One can capture the requirement with the following, different 
  *>    wording: If one views the domain with a QoS technology as a virtual 
  *>    router then NSIS signaling used between those virtual routers MUST 
  *>    follow the same path as the data.  
  *>     
  *>    Routing the signaling protocol along an independent path is desired 
  *>    by network operators/designers. Ideally, the capability to route the 

!! This is a statement without proof, and probably without relevance.
You may be able to justify off-path signaling by architectural
argument about the cleanest/most robust/... way to accomplish some
desirable goal.  But claiming that some people want it, without any
technical justification, is not appropriate.

  *>    protocol along an independent path would give the network 
  *>    designer/operator the option to manage bandwidth utilization through 
  *>    the topology. 
  *>     
  *>    There are other possibilities as well. An NSIS protocol MUST accept 
  *>    all of these possibilities with a strong focus on the on-path 
  *>    signaling.  
  *>  
  *> 5.2.3 Concealment of topology and technology information 
  *>     
  *>    The NSIS protocol SHOULD allow for hiding the internal structure of 
  *>    a NSIS domain from end-nodes and from other networks. Hence an 
  *>    adversary should not be able to learn the internal structure of a 
  *>    network with the help of the signaling protocol. 
  *>     

I think these security requirements need a LOT more thought!  It is
very unclear to me that 5.2.3 is a reasonable requirement, except in
the context of the hierarchical model of section 3.

  *>    In various scenarios, topology information SHOULD be hidden for 
  *>    various reasons. From a business point of view, some administrations 
  *>    don't want to reveal the topology and technology used.  
  *>     
  *> 5.2.4 Transparency of signaling to network 
  *>     
  *>    It SHOULD be possible that the signaling for some flows traverse 
  *>    path segments transparently, i.e., without interpretation at NSIS 
  *>    Forwarders within the network. An example would be a subdomain 
  *>    within a core network, which only interpreted signaling for 
  *>    aggregates established at the domain edge, with the flow-related 
  *>    signaling passing transparently through it. 
  *>     
  *>    In other words, NSIS SHOULD work in hierarchical scenarios, where 
  *>    big pipes/trunks are setup using NSIS signaling, but also flows 
  *>    which run within that big pipe/trunk are setup using NSIS. 

This hierarchical model deserves discussion, maybe even a diagram, in
section 3.

  *>  
  *> 5.3 Additional information beyond signaling for a service 
  *>  
  *> 5.3.1 Explicit release of resources  
  *>     
  *>    When a resource reservation is no longer necessary, e.g. because the 
  *>    application terminates, or because a mobile host experienced a hand-
  *> 
  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 14] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    off, it MUST be possible to explicitly release resources. In general 
  *>    explicit release enhances the overall network utilization. 
  *>     
  *> 5.3.2 Possibility for automatic release of resources after failure 
  *>     
  *>    When the NSIS Initiator goes down, the resources it requested in the 
  *>    network SHOULD be released, since they will no longer be necessary. 
  *>     
  *>    After detection of a failure in the network, any NSIS 
  *>    Forwarder/Initiator MUST be able to release a reservation it is 
  *>    involved in. For example, this may require signaling of the "Release 
  *>    after Failure" message upstream as well as downstream, or soft state 
  *>    timing out of reservations. 
  *>     
  *>    The goal is to prevent stale state within the network and adds 
  *>    robustness to the operation of NSIS. So in other words, an NSIS 
  *>    signaling protocol or mechanisms MUST provide means for an NSIS 
  *>    entity to discover and remove local stale state.  
  *>     
  *>    Note that this might need to work together with a notification 
  *>    mechanism. 
  *>     

Is this section hinting at soft state?  Please clarify.

  *> 5.3.3 Notifications sent upstream 
  *>  
  *>    NSIS Forwarders SHOULD be able to notify the NSIS Initiator or any 
  *>    other NSIS Forwarder upstream, if there is a state change inside the 
  *>    network. There are various types of network changes for instance 
  *>    among them: 
  *>     

Why should an initator always be notified of a failure, even when the
network (routing) is able to recover internally without disturbing the
QoS?

  *>    Recoverable errors: the network nodes can locally repair this type 
  *>    error. The network nodes do not have to notify the users of the 
  *>    error immediately. This is a condition when the danger of 
  *>    degradation (or actual short term degradation) of the provided QoS 
  *>    was overcome by the network (NSIS Forwarder) itself. 
  *>   

Isn't recovery from errors an L3 routing problem?  The relation to
signaling is more subtle than reflected here.

Maybe you need to distinguish data forwarding failures (ie., routing)
from QoS failures (in normal cases, I would expect the latter to be
must less common than the former.)

  *>    Unrecoverable errors: the network nodes cannot handle this type of 
  *>    error, and have to notify the users as soon as possible. 

(If they can reach the users.)

BTW, what is a "user" here?  Not a defined term in this document.

  *>     
  *>    QoS degradation/severe congestion: In case the service cannot be 
  *>    provided completely but partially only. 
  *>     
  *>    Repair indication: If an error occurred and it has been fixed, this 
  *>    triggers the sending of a notification. 
  *>     
  *>    Service upgrade available: If a previously requested better service 
  *>    becomes available. 
  *>  
  *>    The content of the notification is very service specific, but it is 
  *>    must at least carry type information. Additionally, it may carry the 
  *>    location of the state change. 
  *>     
  *>    The notifications may or may not be in response to a NSIS message. 
  *>    This means an NSIS entity has to be able to handle notifications at 
  *>    any time. 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 15] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>     
  *>    Note however, that there are a number of security consideration 
  *>    needs to be solved with notification, even more important if the 
  *>    notification is sent without prior request (asynchronously). The 
  *>    problem basically is, that everybody could send notifications to any 
  *>    NSIS entity and the NSIS entity most likely reacts on the 
  *>    notification. E.g., if it gets an error notification it might 
  *>    teardown the reservation, even if everything is ok. So the 
  *>    notification might depend on security associations between the 
  *>    sender of the notification and its receiver. If a hop-by-hop 
  *>    security mechanism is chosen, this implies also that notifications 
  *>    need to be sent on the reverse path. 
  *>  
  *> 5.3.4 Feedback about success of service request 
  *>     
  *>    A request for service MUST be answered at least with yes or no. 
  *>    However, it MAY be useful in case of a negative answer to also get a 
  *>    description of what amount of resources a request is possible. So an 
  *>    opaque element MAY be included into the answer. The element heavily 
  *>    depends on the service requested. 
  *>  
  *> 5.3.5 Local information exchange  
  *>     
  *>    The signaling protocol MUST be able to exchange local information 
  *>    between NSIS Forwarders located within one single administrative 
  *>    domain. Local information might, for example, be IP addresses, 
  *>    severe congestion notification, notification of successful or 
  *>    erroneous processing of signaling messages. 
  *>     
  *>    In some cases, the NSIS signaling protocol MAY carry identification 
  *>    of the NSIS Forwarders located at the boundaries of a domain. 
  *>    However, the identification of edge should not be visible to the end 
  *>    host (NSIS Initiator) and only applies within one administrative 
  *>    domain. 
  *>     
  *> 5.4 Control Information 
  *>     
  *>    This section contains requirements related to the control 
  *>    information that needs to be exchanged. 
  *>  
  *> 5.4.1 Mutability information on parameters 
  *>     
  *>    It SHOULD be possible for the NSIS initiator to control the 
  *>    mutability of the signaled information. This prevents from being 
  *>    changed in a non-recoverable way. The NSIS initiator SHOULD be able 
  *>    to control what is requested end to end, without the request being 
  *>    gradually mutated as it passes through a sequence of domains. This 
  *>    implies that in case of changes made on the parameters, the original 
  *>    requested ones must still be available.  
  *>     
  *>    Note that we do not require anything about particular parameters 
  *>    being changed.  
  *>     

I have no idea what this section is talking about.  Could you explain
in terms of RSVP, for example?

  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 16] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    Additionally, note that a provider or that particular services 
  *>    requested, can still influence the QoS provisioning but in the 
  *>    signaling message the request should stay the same. 
  *>     
  *> 5.4.2 Possibility to add and remove local domain information  
  *>     
  *>    It SHOULD be possible for the Resource Management Function to add 
  *>    and remove local scope elements. E.g., at the entrance to a domain 
  *>    domain-specific information is added, which is used in this domain 
  *>    only, and the information is removed again when a signaling message 
  *>    leaves the domain. The motivation is in the economy of re-use the 
  *>    protocol for domain internal signaling of various information 
  *>    pieces. Where additional information is needed within a particular 
  *>    domain, it should be possible to carry this at the same time as the 
  *>    end-to-end information. 
  *> 

This gets into an architectural issue.  "Re-use" means?  It could be the
same protocol used hierarchically (as in the adaptation of RSVP to
the Subnet Bandwidth Manager for 802 signaling).  However, it seems 
to mean that the same signaling messages carry "inner" and "outer"
signling requests.  This sounds tricky and needs some careful thought.
Decoupling into two protocols, or two instances of the same protocol,
may be a sounder architecture with fewer feature interactions.

  *> 5.4.3 Independence of reservation identifier 
  *>     
  *>    A reservation identifier, which is independent of the flow 
  *>    identifier (flow end-points), MUST be used. Various scenarios in the 
  *>    mobility area require this independence because flows resulting from 
  *>    handoff might have changed end-points etc. but still have the same 
  *>    service requirement. Also several proxy-based signaling methods 
  *>    might profit from such as independence. 

The semantics of this identifier needs to be precisely defined.  It is
unclear whether it needs to be used E-E, or only in the mobile domain.

  *>     
  *> 5.4.4 Seamless modification of already reserved resources 
  *>     
  *>    In many case, the reservation needs to be updated (up or downgrade). 
  *>    This SHOULD happen seamlessly without service interruption. At least 
  *>    the signaling protocol should allow for it, even if some data path 
  *>    elements might not be capable of doing so.  
  *>     
  *> 5.4.5 Grouping of signaling for several micro-flows 
  *>     
  *>    NSIS MAY group signaling information for several micro-flow into one 
  *>    signaling message. The goal of this is the optimization in terms of 
  *>    setup delay, which can happen in parallel. This helps applications 
  *>    requesting several flows at once. Also potential refreshes (in case 
  *>    of a soft state solution) might profit of grouping.  

I believe we have a term for this in RSVP; it is called bundling.
  *>     
  *>    However, the network MUST NOT know that a relationship between the 
  *>    grouped flows exists. There MUST NOT be any transactional semantic 
  *>    associated with the grouping. It is only meant for optimization 
  *>    purposes and each reservation MUST be handled separately from each 
  *>    other. 
  *>     
  *> 5.5 Performance 
  *>     
  *>    This section discusses performance requirements and evaluation 
  *>    criteria and the way in which these could and should be traded off 
  *>    against each other in various parts of the solution. 
  *>     
  *>    Scalability is a must anyway. However, depending on the scenario the
                              XXXXXX
  *>    question to which extends the protocol must be scalable.  
  *>      
  *>    Brunner (Editor)         Informational                   [Page 17] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>     
  *>    Note that many of the performance issues are heavily dependent on 
  *>    the scenario assumed and are normally a trade-off between speed, 
  *>    reliability, complexity, and scalability. The trade-off varies in 
  *>    different parts of the network. For example, in radio access 
  *>    networks low bandwidth consumption will overweight the low latency 
  *>    requirement, while in core networks it may be reverse. 
  *>     
  *> 5.5.1 Scalability  
  *>     
  *>    NSIS MUST be scalable in the number of messages received by a 
  *>    signaling communication partner (NSIS Initiator, NSIS Forwarder, and 
  *>    NSIS Responder). The major concern lies in the core of the network, 
  *>    where large numbers of messages arrive. 
  *>     

What does "scalable in" mean, exactly?  This statement as written has
no content at all, I am afraid.  Can you give an example of an architectural
design that would NOT satisfy this requirement, for example?

  *>    It MUST be scalable in number of hand-offs in mobile environments. 
  *>    This mainly applies in access networks, because the core is 
  *>    transparent to mobility in most cases. 
  *>     

Ditto.

  *>    It MUST be scalable in the number of interactions for setting up a 
  *>    reservation. This applies for end-systems setting up several 
  *>    reservations. Some servers might be expected to setup a large number 
  *>    of reservations. 
  *>     

Ditto.

  *>    Scalability in the number of state per entity MUST be achieved for 
  *>    NSIS Forwarders in the core of the network. 
  *>     

Ditto.

  *>    And Scalability in CPU use MUST be achieved on end terminals in case 
  *>    of many reservations at the same time and intermediate nodes mainly 
  *>    in the core. 
  *> 

I am REALLY confused by scalability in CPU use.  How can it NOT be
scalable in CPU use??

  *> 5.5.2 Low latency in setup 
  *>     
  *>    NSIS SHOULD allow for low latency setup of reservations. This is 
  *>    only needed in scenarios, where reservations are in a short time 
  *>    scale (e.g. handover in mobile environments), or where human 
  *>    interaction is immediately concerned (e.g., voice communication 
  *>    setup delay).  
  *>     
  *> 5.5.3 Allow for low bandwidth consumption for signaling protocol 
  *>     
  *>    NSIS MUST allow for low bandwidth consumption in certain access 
  *>    networks. Again only small sets of scenarios call for low bandwidth, 
  *>    mainly those where wireless links are involved.  
  *>  
  *> 5.5.4 Ability to constrain load on devices 
  *>     
  *>    The NSIS architecture SHOULD give the ability to constrain the load 
  *>    (CPU load, memory space, signaling bandwidth consumption and 
  *>    signaling intensity) on devices where it is needed. One of the 
  *>    reasons is that the protocol handling should have a minimal impact 
  *>    on interior (core) nodes. 
  *>     
  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 18] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    This can be achieved by many different methods. Examples, and this 
  *>    are only examples, include message aggregation, by ignoring 
  *>    signaling message, header compression, or minimizing functionality. 
  *>    The framework may choose any method as long as the requirement is 
  *>    met. 
  *>     
  *> 5.5.5 Highest possible network utilization 
  *>  
  *>    There are networking environments that require high network 
  *>    utilization for various reasons, and the signaling protocol SHOULD 
  *>    to its best ability support high resource utilization while 
  *>    maintaining appropriate QoS. 

What does this mean, and what can a signaling protocol do/not do to
achieve it?  It seems to me to depend rather upon the QoS technology,
which I believe is out of scope.

  *>     
  *>    In networks where resources are very expensive (as is the case for 
  *>    many wireless networks), efficient network utilization is of 
  *>    critical financial importance.  On the other hand there are other 
  *>    parts of the network where high utilization is not required.  
  *>  
  *> 5.6 Flexibility 
  *>  
  *>    This section lists the various ways the protocol can flexibly be 
  *>    employed. 
  *>     
  *> 5.6.1 Flow aggregation 
  *>     
  *>    NSIS MUST allow for flow aggregation, including the capability to 
  *>    select and change the level of aggregation. 
  *>     
  *> 5.6.2 Flexibility in the placement of the NSIS Initiator 
  *>     
  *>    NSIS MUST be flexible in placing an NSIS Initiator. The NSIS 
  *>    Initiator might be the sender or the receiver of content. But also 
  *>    network-initiated reservations MUST be available in various 
  *>    scenarios such as PSTN gateways, some VPNs, and mobility. 
  *>     

Is this maybe the 3rd time you've said this?

  *> 5.6.3 Flexibility in the initiation of re-negotiation 
  *>     
  *>    The sender or the receiver of content SHOULD be able to initiate a 
  *>    re-negotiation or change the reservation due to various reasons, 
  *>    such as local resource shortage (CPU, memory on end-system) or a 
  *>    user changed application preference/profiles. But also network-
  *>    initiated re-negotiation SHOULD be supported in cases, where the 
  *>    network is not able to further guarantee resources etc. 
  *>     
  *> 5.6.4 Uni / bi-directional reservation 
  *>     
  *>    Both unidirectional as well as bi-direction reservations SHOULD be 
  *>    possible. With bi-directional reservations we mean here reservations 
  *>    having the same end-points. But the path in the two directions does 
  *>    not need to be the same. 
  *>  

?? Incomplete definition

  *> 
  *> 
  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 19] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    The goal of a bi-directional reservation is mainly an optimization 
  *>    in terms of setup delay. There is no requirements on constrains such 
                                                        x or constraint
  *>    as use the same data path etc. 
  *>     

Note that a bi-directional setup seems to further confuse the definitions
of NI, NR, sender-initiation, and receiver-initiation.

  *> 5.7 Security 
  *>     
  *>    This section discusses security-related requirements. For a 
  *>    discussion of security threats see [3]. The NSIS protocol MUST 
  *>    provide means for security, but it MUST be allowed that nodes 
  *>    implementing NSIS signaling do not need use the security means. 
  *>     
  *> 5.7.1 Authentication of signaling requests  
  *>  
  *>    A signaling protocol MUST make provision for enabling various 
  *>    entities to be authenticated against each other using strong 
  *>    authentication mechanisms. The term strong authentication points to 
  *>    the fact that weak plain-text password mechanisms must not be used 
  *>    for authentication. 
  *>  
  *> 5.7.2 Resource Authorization  
  *>  
  *>    The signaling protocol MUST provide means to authorize resource 
  *>    requests. This requirement demands a hook to interact with a policy 
  *>    entity to request authorization data. This allows an authenticated 
  *>    entity to be associated with authorization data and to verify the 
  *>    resource request. Authorization prevents reservations by unauthorized 
  *>    entities, reservations violating policies, and theft of service. 
  *>    Additionally it limits denial of service attacks against parts of the 
  *>    network or the entire network caused by unrestricted reservations. 
  *>    Additionally it might be helpful to provide some means to inform 
  *>    other protocols of participating nodes within the same administrative 
  *>    domain about a previous successful authorization event. 
  *>  
  *> 5.7.3 Integrity protection  
  *>  
  *>    The signaling protocol MUST provide means to protect the message 
  *>    payloads against modifications. Integrity protection prevents an 
  *>    adversary from modifying parts of the signaling message and from 
  *>    mounting denial of service or theft of service type of attacks 
  *>    against network elements participating in the protocol execution. 
  *>  
  *> 5.7.4 Replay protection 
  *>  
  *>    To prevent replay of previous signaling messages the signaling 
  *>    protocol MUST provide means to detect old i.e. already transmitted 
  *>    signaling messages. A solution must cover issues of synchronization 
  *>    problems in the case of a restart or a crash of a participating 
  *>    network element. The use of replay mechanism apart from sequence 
  *>    numbers should be investigated. 

How about old duplicate signaling packets?

  *>  
  *> 5.7.5 Hop-by-hop security 
  *>  
  *>    Hop-by-Hop security SHOULD be supported. It is a well known and 
  *>    proven concept in Quality-of-Service and other signaling protocols 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 20] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    that allows intermediate nodes that actively participate in the 
  *>    protocol to modify the messages as it is required by processing rule. 
  *>    Note that this requirement does not exclude end-to-end or network-to-
  *>    network security of a signaling message. End-to-end security between 
  *>    the initiator and the responder may be used to provide protection of 
  *>    non-mutable data fields. Network-to-network security refers to the 
  *>    protection of messages over various hops but not in an end-to-end 
  *>    manner i.e. protected over a particular network. 
  *>  
  *> 5.7.6 Identity confidentiality and location privacy 
  *>  
  *>    Identity confidentiality SHOULD be supported. It enables privacy and 
  *>    avoids profiling of entities by adversary eavesdropping the signaling 
  *>    traffic along the path. The identity used in the process of 
  *>    authentication may also be hidden to a limited extent from a network 
  *>    to which the initiator is attached. However the identity MUST provide 
  *>    enough information for the nodes in the access network to collect 
  *>    accounting data. 
  *>    Location privacy MAY be supported. It is an issue for the initiator 
  *>    who triggers the signaling protocol. In some scenarios the initiator 
  *>    may not be willing to reveal location information to the responder as 
  *>    part the signaling procedure.  
  *>     
  *> 5.7.7 Denial-of-service attacks 
  *>  
  *>    A signaling protocol SHOULD provide prevention of DoS attacks.  
  *>    To effectively prevent denial-of-service attacks it is necessary that 
  *>    the used security and protocol mechanisms MUST have low computation 
  *>    complexity to verify a resource request prior authenticating the 
  *>    requesting entity. Additionally the signaling protocol and the used 
  *>    security mechanisms SHOULD NOT require large resource consumption 
  *>    (for example main memory or other additional message exchanges) 
  *>    before a successful authentication was done.

Good luck!!
 
  *>  
  *> 5.7.8 Confidentiality of signaling messages 
  *>  
  *>    Based on the signaling information exchanged between nodes 
  *>    participating in the signaling protocol an adversary may learn both 
  *>    the identities and the content of the signaling messages. To prevent 
  *>    this from happening, confidentiality of the signaling message in a 
  *>    hop-by-hop manner MAY be provided. Note that the protection can be 
  *>    provided on a hop-by-hop basis for most message payloads since it is 
  *>    required that entities which actively participating in the signaling 
  *>    protocol must be able to read and eventually modify the content of 
  *>    the signaling messages. 
  *>  
  *> 5.7.9 Ownership of a reservation 
  *>  
  *>    When existing reservations have to be modified then there is a need 
  *>    to use a reservation identifier to uniquely identify the established 
  *>    state. A signaling protocol MUST provide the appropriate security 
  *>    protection to prevent other entities to modify state without having 
  *>    the proper ownership.  
  *>  

This appears to be identical in meaning to 5.7.1, and therefore redundant.

  *>      
  *>    Brunner (Editor)         Informational                   [Page 21] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *> 5.7.10 Hooks with Authentication and Key Agreement protocols 
  *>  
  *>    This requirement covers two subsequent steps before a signaling 
  *>    protocol is executed and the required hooks. First there is a need to 
                            ,

  *>    agree on a specific authentication protocol. Later this protocol is 
  *>    executed and provides authentication and establishes the desired 
  *>    security associations. Using these security associations it is then 
  *>    possible to exchange secured signaling messages.  
  *>     
  *>    The signaling protocol implementation SHOULD provide hooks to 
  *>    interact with protocols that allow the negotiation of authentication 
  *>    and key agreement protocols. Although the negotiation of an 
  *>    authentication and key management protocol within the signaling 
  *>    protocol may be outside the scope it is still required to trigger 
  *>    this exchange in case that no such security association is available.  
  *>    This requirement originates from the fact that more than one key 
  *>    management protocol may be used to provide a security association for 
  *>    the signaling protocol. Hence the communicating entities must be 
  *>    capable to agree on a specific authentication. The selected 
  *>    authentication and key agreement protocol must however be able to 
  *>    create a security association that can be used within the signaling 
  *>    protocol.  
  *>     
  *>    Key management protocols typically require a larger number of 
  *>    messages to be transmitted to allow a session key and the 
  *>    corresponding security association to be derived. To avoid the 
  *>    complex issue of embedding individual authentication and key 
  *>    agreement protocols into a specific signaling protocol it is required 
  *>    that most of these protocols are executed independently (prior to the 
  *>    signaling protocol) and although the key management protocol may be 
  *>    independent there must be a way for the signaling protocol to access 
  *>    and use available (i.e. already established) security associations to 
  *>    avoid executing a separate key management protocol (or instance of 
  *>    the same protocol) for protocols that closely operate together. If no 
  *>    such security association exists then there SHOULD be means for the 
  *>    signaling protocol to dynamically trigger such a protocol.  
  *>     
  *> 5.8 Mobility 
  *>  
  *> 5.8.1 Allow efficient QoS re-establishment after handover 
  *>     
  *>    Handover is an essential function in wireless networks. After 
  *>    handover, the reservation may need to be completely or partially re-
  *>    established due to route changes. The re-establishment may be 
  *>    requested by the mobile node itself or triggered by the access point 
  *>    that the mobile node is attached to.  In the first case, the 
  *>    signaling MUST allow efficient re-establishment after handover.  Re-
  *>    establishment after handover MUST be as quick as possible so that 

"As quick as possible" .. A MUST is a little harsh for so ill-defined a requirement.

  *>    the mobile node does not experience service interruption or service 
  *>    degradation. The re-establishment SHOULD be localized, and not 
  *>    require end-to-end signaling. 
  *>     
  *> 
  *> 
  *>      
  *>    Brunner (Editor)         Informational                   [Page 22] 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *> 5.9 Interworking with other protocols and techniques 
  *>  
  *>    Hooks SHOULD be provided to enable efficient interworking between 
  *>    various protocols and techniques including: 
  *>     
  *> 5.9.1 MUST interwork with IP tunneling 
  *>     
  *>    IP tunneling for various applications MUST be supported. More 
  *>    specifically tunneling for IPSec tunnels are of importance as 
  *>    discussed in Section 4.2. This mainly impacts the identification of 
  *>    flows. Using IPSec parts of information used for flow identification 
  *>    (e.g. transport protocol information and ports) may not be accessible 
  *>    due to encryption.   
  *>  
  *> 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 
  *>     
  *> 5.9.3 MUST be independent from charging model 
  *>     
  *>    Signaling MUST NOT be constrained by charging models or the charging 
  *>    infrastructure used.  
  *>     
  *> 5.9.4 SHOULD provide hooks for AAA protocols 
  *>     
  *>    The security mechanism SHOULD be developed with respect to be able 
  *>    to collect usage records from one or more network elements. 
  *>     
  *> 5.9.5 SHOULD interwork with seamless handoff protocols 
  *>     
  *>    An NSIS protocol SHOULD interwork with seamless handoff protocols 
  *>    such as context transfer and candidate access router (CAR) 
  *>    discovery. The goal to achieve is that signaling works fast enough 
  *>    in case of a handoff, where that protocols might help in one way or 
  *>    the other.  
  *>     
  *> 5.9.6 MAY interwork with non-traditional routing 
  *>     
  *>    NSIS assumes traditional routing, but networks, which do non-
  *>    traditional L3 routing, should not break it. 

Please give me an example of non-traditional L3 routing; I don't know
what you mean.

  *>     
  *> 5.10 Operational 
  *>     
  *> 5.10.1 Ability to assign transport quality to signaling messages. 
  *>     
  *>    The NSIS architecture SHOULD allow the network operator to assign 
  *>    the NSIS protocol messages a certain transport quality. As signaling 
  *>    opens up for possible denial-of-service attacks, this requirement 
  *>    gives the network operator a mean, but also the obligation, to 
  *>    trade-off between signaling latency and the impact (from the 
  *>    signaling messages) on devices within his/her network. From protocol 
  *>    design this requirement states that the protocol messages SHOULD be 
  *>    detectable, at least where the control and assignment of the 
  *>    messages priority is done. 
  *>     
  *>      
  *>    Brunner (Editor)         Informational                   [Page 23] 
  *> 
  *> 
  *>                  Requirements for Signaling Protocols      August 2002 
  *>     
  *>    Furthermore, the protocol design must take into account reliability 
  *>    concerns. Communication reliability is seen as part of the quality 
  *>    assigned to signaling messages. So procedures MUST be defined how an 
  *>    NSIS signaling system behaves if some kind of request it sent stays 
  *>    without answer. The basic transport protocol to be used between 
  *>    adjacent NSIS units MAY ensure message integrity and reliable 
  *>    transport. 
  *>     
  *> 5.10.2 Graceful fail over 
  *>     
  *>    Any unit participating in NSIS signaling MUST NOT cause further 
  *>    damage to other systems involved in NSIS signaling when it has to go 
  *>    out of service. 

?? Sounds like phone-speak for some concept I don't understand.
Do you mean that if an network manager deliberately takes a router
down, the signaling needs to be able to retain the E2E QoS seamlessly?
What is "damage", or "further damage"?

  *>     
  *> 5.10.3 Graceful handling of NSIS entity problems 
  *>     
  *>    NSIS peers SHOULD be able to detect the malfunctioning peer. It may 

Was NSIS peer (what we normally call "neighbor" in Internet-speak)
defined earlier?

  *>    notify the NSIS Initiator or another NSIS entity involved in the 
  *>    signaling process. The NSIS peer may handle the problem itself e.g. 
  *>    switching to a backup NSIS entity. In the latter case note that 
  *>    synchronization of state between the primary and the backup entity 
  *>    is needed. 
  *>     
  *> 6  Security Considerations 
  *>     
  *>    Section 5.8 of this draft provides security related requirements of 
  *>    a signaling protocol. Another document describes security threads 
  *>    for NSIS [3]. 
  *>      
  *> 7  Reference 
  *>     
  *>    [1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 
  *>    "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
  *>    Specification", RFC 2205, September 1997. 
  *>     
  *>    [2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, 
  *>    "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 
  *>    2001. 
  *>  
  *>    [3] Tschofenig, H., "NSIS Threats", <draft-tschofenig-nsis-threats-
  *>    00.txt>, May 2002.  
  *>     
  *> 8  Acknowledgments 
  *>     
  ...

  *>      
9  Author's Addresses 
  *>     
...

  *>  
  *> 10 Appendix: Scenarios/Use cases 
  *>     

...

Sorry, I did not have time to comment on the Appendix.

Bob Braden

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 21 Oct 2002 21:19:42 +0100

Bob,

some comments on (a very few of) your comments, mainly from a framework perspective:

this question pops up periodically in some form (see also threads on route pinning and bidirectional reservations).

i think the basic (simplifying) assumption has been that the route comes first (defining the path) and the signalling comes after it (following the path). [this doesn't prevent a signalling application at some node interacting with something that modifies the path, but the requirement is then just for NSIS to live with that possibility.] since a handoff is a basically a route change, it comes into this category; if we don't make some assumption like this it's impossible to see where nsis stops and things like seamoby CARD start.

i certainly used to think this was a reasonable restriction (and still do, for the 'NSIS base protocol'). but if we are trying to broaden our minds to think of possible NSIS uses (cf. your initial comments) should we also be thinking about signalling applications that set up or modify routes?

> unclear whether it needs to be used E-E, or only in the mobile domain.

we agonised about precisely this detail in the framework document (current status: we don't know.) one point to make is that i don't think you can restrict the scope of the identifier to a 'mobile domain' because route changes due to mobility may have an impact anywhere along the data path (all the way up to the correspondent).

i'd like to imagine, however, that these details could be covered in the framework, provided the requirements document states abstractly why such a capability is a Good Thing. (maybe the requirement should be a SHOULD, because I'm still not clear such an identifier can be practically secured.)

>    traditional L3 routing, should not break it. 
> 

i have to take some responsibility for this slang. it just means [unicast] routing not based deterministically only on L3 destination address (e.g. QoS routing or very fine grained load balancing). probably the requirements document should use more formal language.

Cheers,

Robert H.

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 19:04:54 GMT

*> 
  *> *>    11. Handoff decision and trigger sources: An NSIS protocol is not 
  *> *>    used to trigger handoffs in mobile IP, nor is it used to decide 
  *> > 
  *> > Why not, and who says?
  *> > 
  *> *>    whether to handoff or not. As soon as or in some situation even 
  *> *>    before a handoff happened, an NSIS protocol might be used for 
  *> *>    signaling for QoS again. However, NSIS MUST interwork with several 
  *> *>    protocols for mobility management. 
  *> *>      
  *> 
  *> this question pops up periodically in some form (see also threads on
  *> route pinning and bidirectional reservations).
  *> 
  *> i think the basic (simplifying) assumption has been that the route
  *> comes first (defining the path) and the signalling comes after it
  *> (following the path). [this doesn't prevent a signalling application at
  *> some node interacting with something that modifies the path, but the
  *> requirement is then just for NSIS to live with that possibility.] since
  *> a handoff is a basically a route change, it comes into this category;
  *> if we don't make some assumption like this it's impossible to see where
  *> nsis stops and things like seamoby CARD start.

Robert,

OK, now I understand what you meant.  I think the paragraph should be
more carefully worded.

  *> 
  *> i certainly used to think this was a reasonable restriction (and still
  *> do, for the 'NSIS base protocol'). but if we are trying to broaden our
  *> minds to think of possible NSIS uses (cf. your initial comments) should
  *> we also be thinking about signalling applications that set up or modify
  *> routes?

This is certainly a hard problem, which we struggled with in RSVP.
We took the same approach you suggest, simply because to do anything
else (like entangling QoS signaling with routing) seemed doomed to
complexity death.

  *> 
  *> *> 5.4.3 Independence of reservation identifier 
  *> *>     
  *> *>    A reservation identifier, which is independent of the flow 
  *> *>    identifier (flow end-points), MUST be used. Various scenarios in the 
  *> *>    mobility area require this independence because flows resulting from 
  *> *>    handoff might have changed end-points etc. but still have the same 
  *> *>    service requirement. Also several proxy-based signaling methods 
  *> *>    might profit from such as independence. 
  *> > 
  *> > The semantics of this identifier needs to be precisely defined.  It is
  *> > unclear whether it needs to be used E-E, or only in the mobile domain.
  *> > 
  *> 
  *> we agonised about precisely this detail in the framework document
  *> (current status: we don't know.) one point to make is that i don't
  *> think you can restrict the scope of the identifier to a 'mobile domain'
  *> because route changes due to mobility may have an impact anywhere along
  *> the data path (all the way up to the correspondent).
  *> 

Robert,

I would like to understand myself what the issue is here.  What
function does the identifier serve? Exactly what will be done
differently if you have the identifier?

I can imagine that its function is to prevent "trading" reservations
when end points move, i.e., it allows you to reuse the resources you
already have for an ongoing call, rather than allocating new resources
and freeing the old ones.  Is that right? (If so, it seems like a
second-order optimization that might be nice but is not critical.)

Bob

---

From: [email-masked]
Date: Fri, 25 Oct 2002 12:49:41 +0300

Hi Bob,

> second-order optimization that might be nice but is not critical.)

Have you seen Michael Thomas' analysis of RSVP and Mobile IP?
It is expired, but perhaps I should ask him to revise it.  It 
brings forth some key problems when you mix RSVP & MIP.

John