Subject: RE: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 27 Apr 2004 16:30:54 +0100

jukka,

on your point (2a) it would seem to make more sense to remove
the whole of the final paragraph (the rest doesn't make much
sense without the first sentence, and in the other sections
you've removed the whole equivalent paragraph).

i'd be happy with these changes. in each case, either it's
obvious from the preceding discussion that the functionality
is similar to what is in standard transport protocols or it
isn't; saying so explicitly doesn't add anything, and saying
that re-using the standard transport protocols is the right
design approach is not appropriate in this document anyway.

r.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2004 13:49
> To: John Loughney; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt
> 
> 
> 
> Dear all,
> 
> It seems no one has had problems with the proposed change, 
> neither do I 
> have issues with it - it looks good to me. 
> 
> In addition to that change, Allison commented about Section 3 that 
> suggested too heavily to use TCP with RSVP. I think Section 3 
> has good 
> information, but could be edited a bit in the "message it 
> tries to give".
> 
> In order to get this item finalized once and for all, I propose the 
> following:
> 
> 1. Make the change of text as suggested by Adrian in this email
> 
> 2. Change Section 3 as follows (by removing text that 
> suggests to use TCP 
>    with RSVP, this is an analysis draft, not a new spec):
> 
>   a) Remove first sentece of last paragraph in Sec 3.1, 
> starting with "In 
>      summary, in trying to introduce..."
> 
>   b) Remove last sentence/paragraph of Sec 3.3
> 
>   c) Remove last paragraph of Sec 3.5
> 
> 3. Make minor edits, e.g. check the references
> 
> I could do these changes as soon as I get an "OK" from the 
> WG, and submit 
> the draft. Would we need a new WG Last Call?
> 
> Regards,
> Jukka
> 
> On Fri, 12 Mar 2004 [email-masked] wrote:
> 
> > Hi all,
> > 
> > Here is text that I recieved from Kireeti Kompella & Adrian Farrel.
> > Please review and comment if anyone disagrees.
> > 
> > thanks!
> > John
> > 
> > == forwarded text ==
> > 
> > Here is the text that Adrian had in replacement of sections 2.2.10
> > through 2.2.12, with minor mods from me.
> > 
> > As a whole, this document seems primarily to be more of a 
> "Compendium
> > of Extensions to RSVP and Other Quality of Service Signaling
> > Protocols"  rather than an Analysis of the same.  It is useful as
> > such, but one might consider a change of title.
> > 
> > Kireeti.
> > -------
> > 
> > == BEGIN ORIGINAL TEXT ==
> > 
> > 2.2.10.  MPLS Traffic Engineering
> > 
> >    RSVP-TE [RFC3209] specifies the extension to RSVP for 
> establishing
> >    explicitly routed LSPs in MPLS networks using RSVP as a signaling
> >    protocol. RSVP-TE is intended for use by label switching 
> routers (as
> >    well as hosts) to establish and maintain LSP-tunnels and 
> to reserve
> >    network resources for such LSP-tunnels.  RFC3209 defines 
> a new Hello
> >    message (for rapid node failure detection), new C-Types
> >    (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION 
> (here a session
> >    is implicitly defined as the set of packets that are assigned the
> >    same MPLS label value at the originating node of an LSP-tunnel),
> >    SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new
> >    objects:
> > 
> >    1) EXPLICIT_ROUTE object (ERO), which is incorporated 
> into RSVP Path
> >       messages, encapsulating a concatenation of hops which 
> constitutes
> >       the explicitly routed path. Using this object, the 
> paths taken by
> >       label-switched RSVP-MPLS flows can be pre-determined, 
> independent
> >       of conventional IP routing.
> > 
> >    2) LABEL_REQUEST object. To establish an LSP tunnel, the 
> sender can
> >       create a Path message with a LABEL_REQUEST object. A node that
> >       sends a LABEL_REQUEST object MUST be ready to accept 
> and correctly
> >       process a LABEL object in the corresponding Resv messages.
> > 
> >    3) LABEL object.  Each node that receives a Resv message 
> containing a
> >       LABEL object uses that label for outgoing traffic 
> associated with
> >       this LSP tunnel.
> > 
> >    4) SESSION_ATTRIBUTE object, which can be added to Path 
> messages to
> >       aid in session identification and diagnostics.  
> Additional control
> >       information, such as setup and hold priorities, resource
> >       affinities and local-protection, are also included in 
> this object.
> > 
> >    5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object 
> may appear in
> >       both Path and Resv messages. It is used to collect 
> detailed path
> >       information and is useful for loop detection and for 
> diagnostics.
> > 
> >    Section 5 of RFC3270 further specifies the extensions to RSVP to
> >    establish LSPs supporting DiffServ in MPLS networks, 
> introducing a
> >    new DIFFSERV Object (applicable in the Path messages) 
> and using pre-
> >    configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping".
> > 
> > 
> > 2.2.11.  GMPLS RSVP: Provision Optical Networks
> > 
> >    [RFC3473] is developed on top of RSVP-TE. It enables network
> >    operations to provision data-path within optical networks.  It
> >    defines a Notify message (for general event 
> notification), which may
> >    contain notifications being sent, with respect to each listed
> >    session, both upstream and downstream. Notify messages 
> can be used
> >    together with Notify Request object for expedited notification of
> >    failures and other events to nodes responsible for 
> restoring failed
> >    LSPs. A Notify message is sent without the router alert option.
> >    Besides, a number of new RSVP-TE (sub)objects are 
> defined in GMPLS
> >    RSVP-TE for general uses of MPLS: (for label management:)
> > 
> >    - a Generalized Label Request Object;
> >    - Bandwidth Encoding carried in SENDER_TSPEC and 
> FLOWSPEC objects,
> >      Generalized Label Object;
> >    - a Waveband Switching Object;
> >    - a Suggested Label Object;
> >    - a Label Set Object; (to support bidirectional LSP setup:)
> >    - an Upstream_Label object; (to support uni- and bi-directional
> >      Explicit Label Control:)
> >    - a Label ERO subobject;
> >    - a Label RRO subobject, which is included in RROs as 
> described in
> >      [RFC3209]; (To Control Channel Separation:)
> >    - IF_ID RSVP_HOP objects (IPv4 & v6);
> >    - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure
> >      notification:)
> >    - a Acceptable Label Set object to support Notification on Label
> >      Error;
> >    - a Notify Request object, which may be inserted in Path or Resv
> >      messages to indicate where a notification of LSP 
> failure is to be
> >      sent; (for fault handling:)
> >    - a Restart_Cap Object; (for administrative purposes:)
> >    - an Admin Status Object, which is used to notify each 
> node along the
> >      path of the status of the LSP.
> > 
> >    Since RSVP-TE does not provide a way to indicate an 
> unnumbered link
> >    in its Explicit Route and Record Route Objects, [KoRe03] 
> specifies
> >    extensions to RSVP-TE to support (point-to-point) 
> unnumbered links,
> >    namely,
> > 
> >    - an Unnumbered Interface ID Subobject, which is a new 
> subobject of
> >      the Explicit Route Object (ERO) used to specify 
> unnumbered links;
> >    - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
> >      form or use an identifier for the Forwarding Adjacency;
> >    - a new subobject of the Record Route Object, used to 
> record that the
> >      LSP path traversed an unnumbered link.
> > 
> > 
> > 2.2.12.  GMPLS Interworking with ITU and OIF
> > 
> >    [LiPe02] proposes additional extensions to GMPLS RSVP-TE 
> to support
> >    the capabilities of an Automatically Switched Optical 
> Network (ASON,
> >    an architecture developed by ITU-T SG15).  To support 
> Soft Permanent
> >    Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF-
> >    UNI-1.0] but introduces a new subtype: SPC_LABEL. In 
> addition, a Call
> >    identifier (CALL_ID) object is used in logical call/connection
> >    separation, which are used together with a new Call capability
> >    (CALL_OPS) object for complete call/connection 
> separation. Besides
> >    new error codes, 3 new C-types are defined for the 
> SESSION object:
> >    UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION.
> > 
> >    Optical Internetworking Forum (OIF) UNI 1.0 signaling 
> ([OIF-UNI-1.0])
> >    supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10
> >    types of RSVP(-TE) messages are supported, but used in a slightly
> >    different way.  For example, only FF style is supported; 
> States are
> >    always deleted explicitly; a state timer expiration will 
> not deleted
> >    the state, rather triggers a tear down message; any RSVP 
> message must
> >    be dropped silently when fails security validation.  Besides new
> >    error codes, a few new (sub)objects are introduced, including
> >    [Berg03]:
> > 
> >    - a new C-type for ACCEPTABLE_LABEL_SET;
> >    - a new C-type for ADMIN_STATUS;
> >    - a new C-type for LABEL_SET;
> >    - a new C-type for RECOVER_LABEL;
> >    - a new C-type for RESTART_CAP;
> >    - a new C-type for UPSTEAM_LABEL;
> >    - a UNI_IPv4_SESSION object, combined with
> >      LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a
> >      connection at a local UNI;
> >    - a GENERALIZED_LABEL_REQUEST object;
> >    - a GENERALIZED_UNI_ATTRIBUTES object, which contains 
> one or more new
> >      SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, 
> SERVICE_LEVEL
> >      subobjects. EGRESS_LABEL can be used to specify either uni- or
> >      bi-directional connections;
> >    - a SONET/SDH_SENDER_TSPEC object.
> > 
> > == END ORIGINAL TEXT ==
> > 
> > 
> > == BEGIN NEW TEXT ==
> > 
> > 2.2.10.  MPLS Traffic Engineering
> > 
> >    RSVP-TE [RFC3209] specifies the core extensions to RSVP for
> >    establishing constraint-based explicitly routed LSPs in 
> MPLS networks
> >    using RSVP as a signaling protocol. RSVP-TE is intended 
> for use by
> >    label switching routers (as well as hosts) to establish 
> and maintain
> >    LSP-tunnels and to reserve network resources for such 
> LSP-tunnels.
> > 
> >    RFC3209 defines a new Hello message (for rapid node failure
> >    detection).
> > 
> >    RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and
> >    LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and 
> FILTER_SPEC
> >    objects. Here a session is the association of LSPs that 
> support the
> >    LSP-tunnel. The traffic on an LSP can be classified as the set of
> >    packets that are assigned the same MPLS label value at the
> >    originating node of an LSP-tunnel.
> > 
> >    The following 5 new objects are also defined.
> > 
> >    1) EXPLICIT_ROUTE object (ERO), which is incorporated 
> into RSVP Path
> >       messages, encapsulating a concatenation of hops which 
> constitutes
> >       the explicitly routed path. Using this object, the 
> paths taken by
> >       label-switched RSVP-MPLS flows can be pre-determined, 
> independent
> >       of conventional IP routing.
> > 
> >    2) LABEL_REQUEST object. To establish an LSP tunnel, the 
> sender can
> >       create a Path message with a LABEL_REQUEST object. A node that
> >       sends a LABEL_REQUEST object MUST be ready to accept 
> and correctly
> >       process a LABEL object in the corresponding Resv messages.
> > 
> >    3) LABEL object.  Each node that receives a Resv message 
> containing a
> >       LABEL object uses that label for outgoing traffic 
> associated with
> >       this LSP tunnel.
> > 
> >    4) SESSION_ATTRIBUTE object, which can be added to Path 
> messages to
> >       aid in session identification and diagnostics.  
> Additional control
> >       information, such as setup and holding priorities, resource
> >       affinities and local-protection, are also included in 
> this object.
> > 
> >    5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object 
> may appear in
> >       both Path and Resv messages. It is used to collect 
> detailed path
> >       information and is useful for loop detection and for 
> diagnostics.
> > 
> >    Section 5 of [RFC3270] further specifies the extensions 
> to RSVP to
> >    establish LSPs supporting DiffServ in MPLS networks, 
> introducing a
> >    new DIFFSERV Object (applicable in the Path messages) 
> and using pre-
> >    configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping".
> > 
> >    RSVP-TE provides a way to indicate an unnumbered link in 
> its Explicit
> >    Route and Record Route Objects through [RFC3477]. This 
> specifies the
> >    following extensions.
> > 
> >    - An Unnumbered Interface ID Subobject, which is a 
> subobject of the
> >      Explicit Route Object (ERO) used to specify unnumbered links;
> >    - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
> >      form or use an identifier for an unnumbered Forwarding 
> Adjacency;
> >    - A new subobject of the Record Route Object, used to 
> record that the
> >      LSP path traversed an unnumbered link.
> > 
> > 2.2.11.  GMPLS RSVP: Provisioning for Multiple Switching Types
> > 
> >    GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE.  It 
> enables the
> >    provisioning of data-paths within networks supporting a 
> variety of
> >    switching types including packet and cell switching 
> networks, layer
> >    two networks, TDM networks and photonic networks.
> > 
> >    It defines the new Notify message (for general event 
> notification),
> >    which may contain notifications being sent, with respect to each
> >    listed LSP, both upstream and downstream. Notify 
> messages can be used
> >    for expedited notification of failures and other events to nodes
> >    responsible for restoring failed LSPs. A Notify message is sent
> >    without the router alert option.
> > 
> >    A number of new RSVP-TE (sub)objects are defined in 
> GMPLS RSVP-TE for
> >    general uses of MPLS:
> > 
> >    - a Generalized Label Request Object;
> >    - a Generalized Label Object;
> >    - a Suggested Label Object;
> >    - a Label Set Object; (to restrict label choice)
> >    - an Upstream_Label object; (to support bi-directional LSPs)
> >    - a Label ERO subobject;
> >    - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in
> >      out of band signaling or in bundled links);
> >    - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify 
> interfaces in
> >      out of band signaling or in bundled links);
> >    - an Acceptable Label Set object (to support negotiation of label
> >      values in particular for bidirecitonal LSPs)
> >    - a Notify Request object (may be inserted in a Path or 
> Resv message
> >      to indicate to where a notification of LSP failure is 
> to be sent)
> >    - a Restart_Cap Object (used on Hello messages to 
> identify recovery
> >      capabilities)
> >    - an Admin Status Object (to notify each node along the 
> path of the
> >      status of the LSP, and to control that state).
> > 
> > 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points
> > 
> >    The ITU-T defines nework reference points that separate
> >    administrative or operational parts of the network. The reference
> >    points are designated as:
> >    - User to Network Interfaces (UNIs) if they lie between the user
> >      or user network and the core network.
> >    - External Network to Network Interfaces (E-NNIs) if they lie
> >      between peer networks, network domains, or subnetworks.
> > 
> >    GMPLS is applicable to the UNI and E-NNI without further
> >    modification, and no new messages, objects or C-Types 
> are required.
> >    See [OVERLAY].
> > 
> > 2.2.13. MPLS and GMPLS Future Extensions
> > 
> >    At the time of writing MPLS and GMPLS are being extended 
> by the MPLS
> >    and CCAMP Working Groups to support additional sophisticated
> >    functions. This will inevitably lead to the introduction of new
> >    C-Types for existing objects, and to the requirement for 
> new objects
> >    (CNums). It is  possible that new messages will also be 
> introduced.
> > 
> >    Some of the key features and functions being introduced include:
> > 
> >    - Protection and restoration. Features will be developed 
> to provide
> >      - end-to-end protection
> >      - segment protection
> >      - various protection schemes (1+1, 1:1, 1:n)
> >      - support of extra traffic on backup LSPs
> >    - Diverse path establishment for protection and load sharing
> >    - Point-to-mulitpoint path establishment
> >    - Inter-area and inter-AS path establishment
> >      - with explicit path control
> >      - with bandwidth reservation
> >      - with path diversity
> >    - Support for the requirements of ASON signaling as 
> defined by the
> >      ITU-T, including call and connection separation
> >    - Crankback during LSP setup.
> > 
> > 
> > Additional references
> > 
> >    [RFC3477]        Kompella, K. and Y. Rekhter, 
> "Signalling Unnumbered
> >                     Links in Resource Reservation Protocol - Traffic
> >                     Engineering (RSVP-TE)", RFC 3477, January 2003.
> > 
> >    [OVERLAY]        Swallow, G., Drake, J., Ishimatsu, H., and
> >                     Rekhter, Y., "GMPLS UNI: RSVP Support for the
> >                     Overlay Model", draft-ietf-ccamp-gmpls-overlay-
> >                     03.txt, February 2004, work in progress.
> > 
> > 
> > == END NEW TEXT ==
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 28 Apr 2004 09:10:36 +0300 (EEST)

Agreed.

Jukka