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

From: [email-masked]
Date: Fri, 12 Mar 2004 12:40:45 +0200

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