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

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 27 Apr 2004 15:48:31 +0300 (EEST)

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