RFC 3945 - Generalized Multi-Protocol Label Switching (GMPLS(5)

时间:2006-10-31 来源: 作者: 点击:
Uponreceivingthismessageandobject,theingressnodesendsa PathTear/ReleasemessagedownstreamtoremovetheLSPandnormal RSVP-TE/CR-LDPprocessingtakesplace. Inthesecondusage,theAdminStatusobject/TLViscarriedi
  
   Upon receiving this message and object, the ingress node sends a
   PathTear/Release message downstream to remove the LSP and normal
   RSVP-TE/CR-LDP processing takes place.

   In the second usage, the Admin Status object/TLV is carried in a
   Notification/Label Mapping (with the modification action indicator
   flag set to modify) message to request that the ingress node change
   the administrative state of an LSP.  This allows intermediate and
   egress nodes triggering the setting of administrative status.  In
   particular, this allows intermediate or egress LSRs requesting a
   release of an LSP initiated by the ingress node.

7.18.  Control Channel Separation

   In GMPLS, a control channel be separated from the data channel.
   Indeed, the control channel can be implemented completely out-of-
   band for various reason, e.g., when the data channel cannot carry
   in-band control information.  This issue was even originally
   introduced to MPLS in the context of link bundling.

   In traditional MPLS, there is an implicit one-to-one association of a
   control channel to a data channel.  When such an association is
   present, no additional or special information is required to
   associate a particular LSP setup transaction with a particular data
   channel.

   Otherwise, it is necessary to convey additional information in
   signaling to identify the particular data channel being controlled.
   GMPLS supports explicit data channel identification by providing
   interface identification information.  GMPLS allows the use of a
   number of interface identification schemes including IPv4 or IPv6
   addresses, interface indexes (for unnumbered interfaces) and
   component interfaces (for bundled interfaces), unnumbered bundled
   interfaces are also supported.

   The choice of the data interface to use is always made by the sender
   of the Path/Label Request message, and indicated by including the
   data channel’s interface identifier in the message using a new
   RSVP_HOP object sub-type/Interface TLV.

   For bi-directional LSPs, the sender chooses the data interface in
   each direction.  In all cases but bundling, the upstream interface is
   implied by the downstream interface.  For bundling, the Path/Label
   Request sender explicitly identifies the component interface used in
   each direction.  The new object/TLV is used in Resv/Label Mapping
   message to indicate the downstream node’s usage of the indicated
   interface(s).

   The new object/TLV can contain a list of embedded TLVs, each embedded
   TLV can be an IPv4 address, and IPv6 address, an interface index, a
   downstream component interface ID or an upstream component interface
   ID.  In the last three cases, the embedded TLV contains itself an IP
   address plus an Interface ID, the IP address being used to identify
   the interface ID (it can be the router ID for instance).

   There are cases where it is useful to indicate a specific interface
   associated with an error.  To support these cases the IF_ID
   ERROR_SPEC RSVP Objects are defined.

8.  Forwarding Adjacencies (FA)

   To improve scalability of MPLS TE (and thus GMPLS) it may be useful
   to aggregate multiple TE LSPs inside a bigger TE LSP.  Intermediate
   nodes see the external LSP only.  They do not have to maintain
   forwarding states for each internal LSP, less signaling messages need
   to be exchanged and the external LSP can be somehow protected instead
   (or in addition) to the internal LSPs.  This can considerably
   increase the scalability of the signaling.

   The aggregation is accomplished by (a) an LSR creating a TE LSP, (b)
   the LSR forming a forwarding adjacency out of that LSP (advertising
   this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c)
   allowing other LSRs to use forwarding adjacencies for their path
   computation, and (d) nesting of LSPs originated by other LSRs into
   that LSP (e.g., by using the label stack construct in the case of
   IP).

   ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs
   just as it floods the information about any other links. Consequently
   to this flooding, an LSR has in its TE link state database the
   information about not just conventional links, but FAs as well.

   An LSR, when performing path computation, uses not just conventional
   links, but FAs as well.  Once a path is computed, the LSR uses RSVP-
   TE/CR-LDP for establishing label binding along the path.  FAs need
   simple extensions to signaling and routing protocols.

8.1.  Routing and Forwarding Adjacencies

   Forwarding adjacencies may be represented as either unnumbered or
   numbered links.  A FA can also be a bundle of LSPs between two nodes.

   FAs are advertised as GMPLS TE links such as defined in [HIERARCHY].
   GMPLS TE links are advertised in OSPF and IS-IS such as defined in
   [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  These last two specifications
   enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.

   When a FA is created dynamically, its TE attributes are inherited
   from the FA-LSP that induced its creation.  [HIERARCHY] specifies how
   each TE parameter of the FA is inherited from the FA-LSP.  Note that
   the bandwidth of the FA must be at least as big as the FA-LSP that
   induced it, but may be bigger if only discrete bandwidths are
   available for the FA-LSP.  In general, for dynamically provisioned
   forwarding adjacencies, a policy-based mechanism may be needed to
   associate attributes to forwarding adjacencies.

   A FA advertisement could contain the information about the path taken
   by the FA-LSP associated with that FA.  Other LSRs may use this
   information for path computation.  This information is carried in a
   new OSPF and IS-IS TLV called the Path TLV.

   It is possible that the underlying path information might change over
   time, via configuration updates, or dynamic route modifications,
   resulting in the change of that TLV.

   If forwarding adjacencies are bundled (via link bundling), and if the
   resulting bundled link carries a Path TLV, the underlying path
   followed by each of the FA-LSPs that form the component links must be
   the same.

   It is expected that forwarding adjacencies will not be used for
   establishing IS-IS/OSPF peering relation between the routers at the
   ends of the adjacency.

   LSP hierarchy could exist both with the peer and with the overlay
   models.  With the peer model, the LSP hierarchy is realized via FAs
   and an LSP is both created and used as a TE link by exactly the same
   instance of the control plane.  Creating LSP hierarchies with
   overlays does not involve the concept of FA.  With the overlay model
   an LSP created (and maintained) by one instance of the GMPLS control
   plane is used as a TE link by another instance of the GMPLS control
   plane.  Moreover, the nodes using a TE link are expected to have a
   routing and signaling adjacency.

8.2.  Signaling Aspects

   For the purpose of processing the explicit route in a Path/Request
   message of an LSP that is to be tunneled over a forwarding adjacency,
   an LSR at the head-end of the FA-LSP views the LSR at the tail of
   that FA-LSP as adjacent (one IP hop away).

8.3.  Cascading of Forwarding Adjacencies

   With an integrated model, several layers are controlled using the
   same routing and signaling protocols.  A network may then have links
   with different multiplexing/demultiplexing capabilities.  For
   example, a node may be able to multiplex/demultiplex individual
   packets on a given link, and may be able to multiplex/demultiplex
   channels within a SONET payload on other links.

   A new OSPF and IS-IS sub-TLV has been defined to advertise the
   multiplexing capability of each interface: PSC, L2SC, TDM, LSC or
   FSC.  This sub-TLV is called the Interface Switching Capability
   Descriptor sub-TLV, which complements the sub-TLVs defined in

   [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  The information carried in this
   sub-TLV is used to construct LSP regions, and determine region’s
   boundaries.

   Path computation may take into account region boundaries when
   computing a path for an LSP.  For example, path computation may
   restrict the path taken by an LSP to only the links whose
   multiplexing/demultiplexing capability is PSC.  When an LSP need to
   cross a region boundary, it can trigger the establishment of an FA at
   the underlying layer (i.e., the L2SC layer).  This can trigger a
   cascading of FAs between layers with the following obvious order:
   L2SC, then TDM, then LSC, and then finally FSC.

9.  Routing and Signaling Adjacencies

   By definition, two nodes have a routing (IS-IS/OSPF) adjacency if
   they are neighbors in the IS-IS/OSPF sense.

   By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency
   if they are neighbors in the RSVP-TE/CR-LDP sense.  Nodes A and B are
   RSVP-TE neighbors if they directly exchange RSVP-TE messages
   (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of
   [HIERARCHY]).  The neighbor relationship includes exchanging RSVP-TE
   Hellos.

   By definition, a Forwarding Adjacency (FA) is a TE Link between two
   GMPLS nodes whose path transits one or more other (G)MPLS nodes in
   the same instance of the (G)MPLS control plane.  If two nodes have
   one or more non-FA TE Links between them, these two nodes are
   expected (although not required) to have a routing adjacency.  If two
   nodes do not have any non-FA TE Links between them, it is expected
   (although not required) that these two nodes would not have a routing
   adjacency.  To state the obvious, if the TE links between two nodes
   are to be used for establishing LSPs, the two nodes must have a
   signaling adjacency.

   If one wants to establish routing and/or signaling adjacency between
   two nodes, there must be an IP path between them.  This IP path can
   be, for example, a TE Link with an interface switching capability of
   PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a
   (bi-directional) LSP that with an interface switching capability of
   PSC).

   A TE link may not be capable of being used directly for maintaining
   routing and/or signaling adjacencies.  This is because GMPLS routing
   and signaling adjacencies requires exchanging data on a per frame/
   packet basis, and a TE link (e.g., a link between OXCs) may not be
   capable of exchanging data on a per packet basis.  In this case, the

   routing and signaling adjacencies are maintained via a set of one or
   more control channels (see [LMP]).

   Two nodes may have a TE link between them even if they do not have a
   routing adjacency.  Naturally, each node must run OSPF/IS-IS with
   GMPLS extensions in order for that TE link to be advertised.  More
   precisely, the node needs to run GMPLS extensions for TE Links with
   an interface switching capability (see [GMPLS-ROUTING]) other than
   PSC.  Moreover, this node needs to run either GMPLS or MPLS
   extensions for TE links with an interface switching capability of
   PSC.

   The mechanisms for Control Channel Separation [RFC3471] should be
   used (even if the IP path between two nodes is a TE link).  I.e.,
   RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object
   to specify a particular TE link when establishing an LSP.

   The IP path could consist of multiple IP hops.  In this case, the
   mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used
   (in addition to Control Channel Separation).

10.  Control Plane Fault Handling

   Two major types of faults can impact a control plane.  The first,
   referred to as control channel fault, relates to the case where
   control communication is lost between two neighboring nodes.  If the
   control channel is embedded with the data channel, data channel
   recovery procedure should solve the problem.  If the control channel
   is independent of the data channel, additional procedures are
   required to recover from that problem.

   The second, referred to as nodal faults, relates to the case where
   node loses its control state (e.g., after a restart) but does not
   loose its data forwarding state.

   In transport networks, such types of control plane faults should not
   have service impact on the existing connections.  Under such
   circumstances, a mechanism must exist to detect a control
   communication failure and a recovery procedure must guarantee
   connection integrity at both ends of the control channel.

   For a control channel fault, once communication is restored routing
   protocols are naturally able to recover but the underlying signaling
   protocols must indicate that the nodes have maintained their state
   through the failure.  The signaling protocol must also ensure that
   any state changes that were instantiated during the failure are
   synchronized between the nodes.

   For a nodal fault, a node’s control plane restarts and loses most of
   its state information.  In this case, both upstream and downstream
   nodes must synchronize their state information with the restarted
   node.  In order for any resynchronization to occur the node
   undergoing the restart will need to preserve some information, such
   as it’s mappings of incoming to outgoing labels.

   These issues are addressed in protocol specific fashions, see
   [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  Note that
   these cases only apply when there are mechanisms to detect data
   channel failures independent of control channel failures.

   The LDP Fault tolerance (see [RFC3479]) specifies the procedures to
   recover from a control channel failure.  [RFC3473] specifies how to
   recover from both a control channel failure and a node failure.

11.  LSP Protection and Restoration

   This section discusses Protection and Restoration (P&R) issues for
   GMPLS LSPs.  It is driven by the requirements outlined in [RFC3386]
   and some of the principles outlined in [RFC3469].  It will be
   enhanced, as more GMPLS P&R mechanisms are defined.  The scope of
   this section is clarified hereafter:

   -  This section is only applicable when a fault impacting LSP(s)
      happens in the data/transport plane.  Section 10 deals with
      control plane fault handling for nodal and control channel faults.

   -  This section focuses on P&R at the TDM, LSC and FSC layers.  There
      are specific P&R requirements at these layers not present at the
      PSC layer.

   -  This section focuses on intra-area P&R as opposed to inter-area
      P&R and even inter-domain P&R.  Note that P&R can even be more
      restricted, e.g., to a collection of like customer equipment, or a
      collection of equipment of like capabilities, in one single
      routing area.

   -  This section focuses on intra-layer P&R (horizontal hierarchy as
      defined in [RFC3386]) as opposed to the inter-layer P&R (vertical
      hierarchy).

   -  P&R mechanisms are in general designed to handle single failures,
      which makes SRLG diversity a necessity.  Recovery from multiple
      failures requires further study.

   -  Both mesh and ring-like topologies are supported.

   In the following, we assume that:

   -  TDM, LSC and FSC devices are more generally committing recovery
      resources in a non-best effort way.  Recovery resources are either
      allocated (thus used) or at least logically reserved (whether used
      or not by preemptable extra traffic but unavailable anyway for
      regular working traffic).

   -  Shared P&R mechanisms are valuable to operators in order to
      maximize their network utilization.

   -  Sending preemptable excess traffic on recovery resources is a
      valuable feature for operators.

11.1.  Protection Escalation across Domains and Layers

   To describe the P&R architecture, one must consider two dimensions of
   hierarchy [RFC3386]:

   -  A horizontal hierarchy consisting of multiple P&R domains, which
      is important in an LSP based protection scheme.  The scope of P&R
      may extend over a link (or span), an administrative domain or
      sub-network, an entire LSP.

      An administrative domain may consist of a single P&R domain or as
      a concatenation of several smaller P&R domains.  The operator can
      configure P&R domains, based on customers’ requirements, and on
      network topology and traffic engineering constraints.

   -  A vertical hierarchy consisting of multiple layers of P&R with
      varying granularities (packet flows, STS trails, lightpaths,
      fibers, etc).

      In the absence of adequate P&R coordination, a fault may propagate
      from one level to the next within a P&R hierarchy.  It can lead to
      "collisions" and simultaneous recovery actions may lead to race
      conditions, reduced resource utilization, or instabilities
      [MANCHESTER].  Thus, a consistent escalation strategy is needed to
      coordinate recovery across domains and layers.  The fact that
      GMPLS can be used at different layers could simplify this
      coordination.

      There are two types of escalation strategies: bottom-up and top-
      down.  The bottom-up approach assumes that "lower-level" recovery
      schemes are more expedient.  Therefore we can inhibit or hold off

      higher-level P&R.  The Top-down approach attempts service P&R at
      the higher levels before invoking "lower level" P&R.  Higher-layer
      P&R is service selective, and permits "per-CoS" or "per-LSP" re-
      routing.

   Service Level Agreements (SLAs) between network operators and their
   clients are needed to determine the necessary time scales for P&R at
   each layer and at each domain.

11.2.  Mapping of Services to P&R Resources

   The choice of a P&R scheme is a tradeoff between network utilization
   (cost) and service interruption time.  In light of this tradeoff,
   network service providers are expected to support a range of
   different service offerings or service levels.

   One can classify LSPs into one of a small set of service levels.
   Among other things, these service levels define the reliability
   characteristics of the LSP.  The service level associated with a
   given LSP is mapped to one or more P&R schemes during LSP
   establishment.  An advantage that mapping is that an LSP may use
   different P&E schemes in different segments of a network (e.g., some
   links may be span protected, whilst other segments of the LSP may
   utilize ring protection).  These details are likely to be service
   provider specific.

   An alternative to using service levels is for an application to
   specify the set of specific P&R mechanisms to be used when
   establishing the LSP.  This allows greater flexibility in using
   different mechanisms to meet the application requirements.

   A differentiator between these service levels is service interruption
   time in case of network failures, which is defined as the length of
   time between when a failure occurs and when connectivity is re-
   established.  The choice of service level (or P&R scheme) should be
   dictated by the service requirements of different applications.

11.3.  Classification of P&R Mechanism Characteristics

   The following figure provides a classification of the possible
   provisioning types of recovery LSPs, and of the levels of overbooking
   that is possible for them.

                 +-Computed on  +-Established     +-Resources pre-
                 | demand       | on demand       | allocated
                 |              |                 |
   Recovery LSP  |              |                 |
   Provisioning -+-Pre computed +-Pre established +-Resources allocated
                                                    on demand

                  +--- Dedicated (1:1, 1+1)
                  |
                  |
                  +--- Shared (1:N, Ring, Shared mesh)
                  |
   Level of       |
   Overbooking ---+--- Best effort

11.4.  Different Stages in P&R

   Recovery from a network fault or impairment takes place in several
   stages as discussed in [RFC3469], including fault detection, fault
   localization, notification, recovery (i.e., the P&R itself) and
   reversion of traffic (i.e., returning the traffic to the original
   working LSP or to a new one).

   -  Fault detection is technology and implementation dependent.  In
      general, failures are detected by lower layer mechanisms (e.g.,
      SONET/SDH, Loss-of-Light (LOL)).  When a node detects a failure,
      an alarm may be passed up to a GMPLS entity, which will take
      appropriate actions, or the alarm may be propagated at the lower
      layer (e.g., SONET/SDH AIS).

   -  Fault localization can be done with the help of GMPLS, e.g., using
      LMP for fault localization (see section 6.4).

   -  Fault notification can also be achieved through GMPLS, e.g., using
      GMPLS RSVP-TE/CR-LDP notification (see section 7.12).

   -  This section focuses on the different mechanisms available for
      recovery and reversion of traffic once fault detection,
      localization and notification have taken place.

11.5.  Recovery Strategies

   Network P&R techniques can be divided into Protection and
   Restoration.  In protection, resources between the protection
   endpoints are established before failure, and connectivity after
   failure is achieved simply by switching performed at the protection
   end-points.  In contrast, restoration uses signaling after failure to
   allocate resources along the recovery path.

   -  Protection aims at extremely fast reaction times and may rely on
      the use of overhead control fields for achieving end-point
      coordination.  Protection for SONET/SDH networks is described in
      [ITUT-G.841] and [ANSI-T1.105].  Protection mechanisms can be
      further classified by the level of redundancy and sharing.

   -  Restoration mechanisms rely on signaling protocols to coordinate
      switching actions during recovery, and may involve simple re-
      provisioning, i.e., signaling only at the time of recovery; or
      pre-signaling, i.e., signaling prior to recovery.

   In addition, P&R can be applied on a local or end-to-end basis.  In
   the local approach, P&R is focused on the local proximity of the
   fault in order to reduce delay in restoring service.  In the end-to-
   end approach, the LSP originating and terminating nodes control
   recovery.

   Using these strategies, the following recovery mechanisms can be
   defined.

11.6.  Recovery mechanisms: Protection schemes

   Note that protection schemes are usually defined in technology
   specific ways, but this does not preclude other solutions.

   -  1+1 Link Protection: Two pre-provisioned resources are used in
      parallel.  For example, data is transmitted simultaneously on two
      parallel links and a selector is used at the receiving node to
      choose the best source (see also [GMPLS-FUNCT]).

   -  1:N Link Protection: Working and protecting resources (N working,
      1 backup) are pre-provisioned.  If a working resource fails, the
      data is switched to the protecting resource, using a coordination
      mechanism (e.g., in overhead bytes).  More generally, N working
      and M protecting resources can be assigned for M:N link protection
      (see also [GMPLS-FUNCT]).

   -  Enhanced Protection: Various mechanisms such as protection rings
      can be used to enhance the level of protection beyond single link
      failures to include the ability to switch around a node failure or
      multiple link failures within a span, based on a pre-established
      topology of protection resources (note: no reference available at
      publication time).

   -  1+1 LSP Protection: Simultaneous data transmission on working and
      protecting LSPs and tail-end selection can be applied (see also
      [GMPLS-FUNCT]).

11.7.  Recovery mechanisms: Restoration schemes

   Thanks to the use of a distributed control plane like GMPLS,
   restoration is possible in multiple of tenths of milliseconds.  It is
   much harder to achieve when only an NMS is used and can only be done
   in that case in a multiple of seconds.

   -  End-to-end LSP restoration with re-provisioning: an end-to-end
      restoration path is established after failure.  The restoration
      path may be dynamically calculated after failure, or pre-
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容