GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4652

Network Working Group D. Papadimitriou, Ed. Request for Comments: 4652 Alcatel Category: Informational L.Ong

                                                                 Ciena
                                                             J. Sadler
                                                               Tellabs
                                                               S. Shew
                                                                Nortel
                                                               D. Ward
                                                                 Cisco
                                                          October 2006
         Evaluation of Existing Routing Protocols against
  Automatic Switched Optical Network (ASON) Routing Requirements

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 The Generalized MPLS (GMPLS) suite of protocols has been defined to
 control different switching technologies as well as different
 applications.  These include support for requesting TDM connections
 including Synchronous Optical Network/Synchronous Digital Hierarchy
 (SONET/SDH) and Optical Transport Networks (OTNs).
 This document provides an evaluation of the IETF Routing Protocols
 against the routing requirements for an Automatically Switched
 Optical Network (ASON) as defined by ITU-T.

Papadimitriou, et al. Informational [Page 1] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

1. Introduction

 Certain capabilities are needed to support the ITU-T Automatically
 Switched Optical Network (ASON) control plane architecture as defined
 in [G.8080].
 [RFC4258] details the routing requirements for the GMPLS routing
 suite of protocols to support the capabilities and functionality of
 ASON control planes identified in [G.7715] and in [G.7715.1].  The
 ASON routing architecture provides for a conceptual reference
 architecture, with definition of functional components and common
 information elements to enable end-to-end routing in the case of
 protocol heterogeneity and to facilitate management of ASON networks.
 This description is only conceptual: no physical partitioning of
 these functions is implied.
 However, [RFC4258] does not address GMPLS routing protocol
 applicability or capabilities.  This document evaluates the IETF
 Routing Protocols against the requirements identified in [RFC4258].
 The result of this evaluation is detailed in Section 5.  Close
 examination of applicability scenarios and the result of the
 evaluation of these scenarios are provided in Section 6.
 ASON (Routing) terminology sections are provided in Appendices A and
 B.

2. Conventions Used in This Document

 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 [RFC2119].
 The reader is expected to be familiar with the terminology introduced
 in [RFC4258].

3. Contributors

 This document is the result of the CCAMP Working Group ASON Routing
 Solution design team's joint effort.
    Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
       EMail: dimitri.papadimitriou@alcatel.be
    Chris Hopps (Cisco)
       EMail: chopps@rawdofmt.org
    Lyndon Ong (Ciena Corporation)
       EMail: lyong@ciena.com
    Jonathan Sadler (Tellabs)
       EMail: jonathan.sadler@tellabs.com

Papadimitriou, et al. Informational [Page 2] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

    Stephen Shew (Nortel Networks)
       EMail: sdshew@nortel.com
    Dave Ward (Cisco)
       EMail: dward@cisco.com

4. Requirements: Overview

 The following functionality is expected from GMPLS routing protocols
 to instantiate the ASON hierarchical routing architecture realization
 (see [G.7715] and [G.7715.1]):
  1. Routing Areas (RAs) shall be uniquely identifiable within a

carrier's network, each having a unique RA Identifier (RA ID)

   within the carrier's network.
  1. Within a RA (one level), the routing protocol shall support

dissemination of hierarchical routing information (including

   summarized routing information for other levels) in support of an
   architecture of multiple hierarchical levels of RAs; the number of
   hierarchical RA levels to be supported by a routing protocol is
   implementation specific.
  1. The routing protocol shall support routing information based on a

common set of information elements as defined in [G.7715] and

   [G.7715.1], divided between attributes pertaining to links and
   abstract nodes (each representing either a sub-network or simply a
   node).  [G.7715] recognizes that the manner in which the routing
   information is represented and exchanged will vary with the routing
   protocol used.
  1. The routing protocol shall converge such that the distributed

Routing DataBases (RDB) become synchronized after a period of time.

 To support dissemination of hierarchical routing information, the
 routing protocol must deliver:
  1. Processing of routing information exchanged between adjacent levels

of the hierarchy (i.e., Level N+1 and N), including reachability

   and (upon policy decision) summarized topology information.
  1. Self-consistent information at the receiving level resulting from

any transformation (filter, summarize, etc.) and forwarding of

   information from one Routing Controller (RC) to RC(s) at different
   levels when multiple RCs are bound to a single RA.
  1. A mechanism to prevent re-introduction of information propagated

into the Level N RA's RC back to the adjacent level RA's RC from

   which this information has been initially received.

Papadimitriou, et al. Informational [Page 3] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Note: The number of hierarchical levels to be supported is routing
 protocol specific and reflects a containment relationship.
 Reachability information may be advertised either as a set of UNI
 Transport Resource address prefixes, or as a set of associated
 Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned
 and selected consistently in their applicability scope.  The formats
 of the control plane identifiers in a protocol realization are
 implementation specific.  Use of a routing protocol within a RA
 should not restrict the choice of routing protocols for use in other
 RAs (child or parent).
 As ASON does not restrict the control plane architecture choice,
 either a co-located architecture or a physically separated
 architecture may be used.  A collection of links and nodes, such as a
 sub-network or RA, must be able to represent itself to the wider
 network as a single logical entity with only its external links
 visible to the topology database.

5. Evaluation

 This section evaluates support of existing IETF routing protocols
 with respect to the requirements summarized from [RFC4258] in Section
 4.  Candidate routing protocols are Interior Gateway Protocol (IGP)
 (OSPF and Intermediate System to Intermediate System (IS-IS)) and
 BGP.  The latter is not addressed in the current version of this
 document.  BGP is not considered a candidate protocol mainly because
 of the following reasons:
  1. Non-support of TE information exchange. Each BGP router advertises

only its path to each destination in its vector for loop avoidance,

   with no costs or hop counts; each BGP router knows little about
   network topology.
  1. BGP can only advertise routes that are eligible for use (local RIB)

or routing loops can occur; there is one best route per prefix, and

   that is the route that is advertised.
  1. BGP is not widely deployed in optical equipment and networks.

5.1. Terminology and Identification

  1. Pi is a physical (bearer/data/transport plane) node.
  1. Li is a logical control plane entity that is associated to a single

data plane (abstract) node. The Li is identified by the TE

   Router_ID.  The latter is a control plane identifier defined as
   follows:

Papadimitriou, et al. Informational [Page 4] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

      [RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
      [RFC3784]: Traffic Engineering Router ID TLV (Type 134)
   Note: This document does not define what the TE Router ID is.  This
   document simply states the use of the TE Router ID to identify Li.
   [RFC3630] and [RFC3784] provide the definitions.
  1. Ri is a logical control plane entity that is associated to a

control plane "router". The latter is the source for topology

   information that it generates and shares with other control plane
   "routers".  The Ri is identified by the (advertising) Router_ID
      [RFC2328]: Router ID (32-bit)
      [RFC1195]: IS-IS System ID (48-bit)
   The Router_ID, which is represented by Ri and which corresponds to
   the RC_ID [RFC4258], does not enter into the identification of the
   logical entities representing the data plane resources such as
   links.  The Routing DataBase (RDB) is associated to the Ri.  Note
   that, in the ASON context, an arrangement consisting of multiple
   Ris announcing routing information related to a single Li is under
   evaluation.
 Aside from the Li/Pi mappings, these identifiers are not assumed to
 be in a particular entity relationship except that the Ri may have
 multiple Lis in its scope.  The relationship between Ri and Li is
 simple at any moment in time: an Li may be advertised by only one Ri
 at any time.  However, an Ri may advertise a set of one or more Lis.
 Thus, the routing protocol MUST be able to advertise multiple TE
 Router IDs (see Section 5.7).
 Note: Si is a control plane signaling function associated with one or
 more Lis.  This document does not assume any specific constraint on
 the relationship between Si and Li.  This document does not discuss
 issues of control plane accessibility for the signaling function, and
 it makes no assumptions about how control plane accessibility to the
 Si is achieved.

5.2. RA Identification

 G.7715.1 notes some necessary characteristics for RA identifiers,
 e.g., that they may provide scope for the Ri, and that they must be
 provisioned to be unique within an administrative domain.  The RA ID
 format itself is allowed to be derived from any global address space.
 Provisioning of RA IDs for uniqueness is outside the scope of this
 document.

Papadimitriou, et al. Informational [Page 5] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Under these conditions, GMPLS link state routing protocols provide
 the capability for RA Identification without further modification.

5.3. Routing Information Exchange

 In this section, the focus is on routing information exchange Ri
 entities (through routing adjacencies) within a single hierarchical
 level.  Routing information mapping between levels require specific
 processing (see Section 5.5).
 The control plane does not transport Pi identifiers, as these are
 data plane addresses for which the Li/Pi mapping is kept (link)
 local; see, for instance the transport LMP document [RFC4394] where
 such an exchange is described.  Example: The transport plane
 identifier is the Pi (the identifier assigned to the physical
 element) that could be, for instance, "666B.F999.AF10.222C", whereas
 the control plane identifier is the Li (the identifier assigned by
 the control plane), which could be, for instance, "192.0.2.1".
 The control plane exchanges the control plane identifier information,
 but not the transport plane identifier information (i.e., not
 "666B.F999.AF10.222C", but only "192.0.2.1").  The mapping Li/Pi is
 kept local.  So, when the Si receives a control plane message
 requesting the use of "192.0.2.1", Si knows locally that this
 information refers to the data plane entity identified by the
 transport plane identifier "666B.F999.AF10.222C".
 Note also that the Li and Pi addressing spaces may be identical.
 The control plane carries:
 1) its view of the data plane link end-points and other link
    connection end-points.
 2) the identifiers scoped by the Lis, i.e., referred to as an
    associated IPv4/IPv6 addressing space.  Note that these
    identifiers may be either bundled TE link addresses or component
    link addresses.
 3) when using OSPF or ISIS as the IGP in support of traffic
    engineering, [RFC3477] RECOMMENDS that the Li value (referred to
    the "LSR Router ID") be set to the TE Router ID value.
 Therefore, OSPF and IS-IS carry sufficient node identification
 information without further modification.

Papadimitriou, et al. Informational [Page 6] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

5.3.1. Link Attributes

 [RFC4258] provides a list of link attributes and characteristics that
 need to be advertised by a routing protocol.  All TE link attributes
 and characteristics are currently handled by OSPF and IS-IS (see
 Table 1) with the exception of Local Adaptation support.  Indeed,
 GMPLS routing does not currently consider the use of dedicated TE
 link attribute(s) to describe the cross/inter-layer relationships.
 In addition, the representation of bandwidth requires further
 consideration.  GMPLS Routing defines an Interface Switching
 Capability Descriptor (ISCD) that delivers information about the
 (maximum/ minimum) bandwidth per priority of which an LSP can make
 use.  This information is usually used in combination with the
 Unreserved Bandwidth sub-TLV that provides the amount of bandwidth
 not yet reserved on a TE link.
 In the ASON context, other bandwidth accounting representations are
 possible, e.g., in terms of a set of tuples <signal_type; number of
 unallocated timeslots>.  The latter representation may also require
 definition of additional signal types (from those defined in
 [RFC3946]) to represent support of contiguously concatenated signals,
 i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
 However, the method proposed in [RFC4202] is the most straightforward
 without requiring any bandwidth accounting change from an LSR
 perspective (in particular, when the ISCD sub-TLV information is
 combined with the information provided by the Unreserved Bandwidth
 sub-TLV).

Papadimitriou, et al. Informational [Page 7] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Link Characteristics     GMPLS OSPF
 -----------------------  ----------
 Local SNPP link ID       Link-local part of the TE link identifier
                          sub-TLV [RFC4203]
 Remote SNPP link ID      Link remote part of the TE link identifier
                          sub-TLV [RFC4203]
 Signal Type              Technology specific part of the Interface
                          Switching Capability Descriptor sub-TLV
                          [RFC4203]
 Link Weight              TE metric sub-TLV [RFC3630]
 Resource Class           Administrative Group sub-TLV [RFC3630]
 Local Connection Types   Switching Capability field part of the
                          Interface Switching Capability Descriptor
                          sub-TLV [RFC4203]
 Link Capacity            Unreserved bandwidth sub-TLV [RFC3630]
                          Max LSP Bandwidth part of the Interface
                          Switching Capability Descriptor sub-TLV
                          [RFC4203]
 Link Availability        Link Protection sub-TLV [RFC4203]
 Diversity Support        SRLG sub-TLV [RFC4203]
 Local Adaptation support See above
              Table 1.  TE link attributes in GMPLS OSPF-TE
 Link Characteristics     GMPLS IS-IS
 -----------------------  -----------
 Local SNPP link ID       Link-local part of the TE link identifier
                          sub-TLV [RFC4205]
 Remote SNPP link ID      Link-remote part of the TE link identifier
                          sub-TLV [RFC4205]
 Signal Type              Technology specific part of the Interface
                          Switching Capability Descriptor sub-TLV
                          [RFC4205]
 Link Weight              TE Default metric [RFC3784]
 Resource Class           Administrative Group sub-TLV [RFC3784]
 Local Connection Types   Switching Capability field part of the
                          Interface Switching Capability Descriptor
                          sub-TLV [RFC4205]
 Link Capacity            Unreserved bandwidth sub-TLV [RFC3784]
                          Max LSP Bandwidth part of the Interface
                          Switching Capability Descriptor sub-TLV
                          [RFC4205]
 Link Availability        Link Protection sub-TLV [RFC4205]
 Diversity Support        SRLG sub-TLV [RFC4205]
 Local Adaptation support See above
             Table 2.  TE link attributes in GMPLS IS-IS-TE

Papadimitriou, et al. Informational [Page 8] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Note: Link Attributes represent layer resource capabilities and
 their utilization i.e. the IGP should be able to advertise these
 attributes on a per-layer basis.

5.3.2. Node Attributes

 Node attributes are the "Logical Node ID" (described in Section 5.1)
 and the reachability information described in Section 5.3.3.

5.3.3. Reachability Information

 Advertisement of reachability can be achieved using the techniques
 described in [OSPF-NODE], where the set of local addresses are
 carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is
 defined per address family, e.g., IPv4 and IPv6).  However,
 [OSPF-NODE] is restricted to advertisement of Host addresses and not
 prefixes, and therefore it requires enhancement (see below).  Thus,
 in order to advertise blocks of reachable address prefixes a
 summarization mechanism is additionally required.  This mechanism may
 take the form of a prefix length (which indicates the number of
 significant bits in the prefix) or a network mask.
 A similar mechanism does not exist for IS-IS.  Moreover, the Extended
 IP Reachability TLV [RFC3784] focuses on IP reachable end-points
 (terminating points), as its name indicates.

5.4. Routing Information Abstraction

 G.7715.1 describes both static and dynamic methods for abstraction of
 routing information for advertisement at a different level of the
 routing hierarchy.  However, the information that is advertised
 continues to be in the form of link and node advertisements
 consistent with the link state routing protocol used at that level.
 Hence, no specific capabilities need to be added to the routing
 protocol beyond the ability to locally identify when routing
 information originates outside of a particular RA.
 The methods used for abstraction of routing information are outside
 the scope of GMPLS routing protocols.

5.5. Dissemination of Routing Information in Support of Multiple

    Hierarchal Levels of RAs
 G.7715.1 does not define specific mechanisms to support multiple
 hierarchical levels of RAs beyond the ability to support abstraction
 as discussed above.  However, if RCs bound to adjacent levels of the
 RA hierarchy are allowed to redistribute routing information in both

Papadimitriou, et al. Informational [Page 9] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 directions between adjacent levels of the hierarchy without any
 additional mechanisms, they would not be able to determine looping of
 routing information.
 To prevent this looping of routing information between levels, IS-IS
 [RFC1195] allows only advertising routing information upward in the
 level hierarchy and disallows the advertising of routing information
 downward in the hierarchy.  [RFC2966] defines the up/down bit to
 allow advertising downward in the hierarchy the "IP Internal
 Reachability Information" TLV (Type 128) and "IP External
 Reachability Information" TLV (Type 130).  [RFC3784] extends its
 applicability for the "Extended IP Reachability" TLV (Type 135).
 Using this mechanism, the up/down bit is set to 0 when routing
 information is first injected into IS-IS.  If routing information is
 advertised from a higher level to a lower level, the up/down bit is
 set to 1, indicating that it has traveled down the hierarchy.
 Routing information that has the up/down bit set to 1 may only be
 advertised down the hierarchy, i.e., to lower levels.  This mechanism
 applies independently of the number of levels.  However, this
 mechanism does not apply to the "Extended IS Reachability" TLV (Type
 22) used to propagate the summarized topology (see Section 5.3),
 traffic engineering information as listed in Table 1, as well as
 reachability information (see Section 5.3.3).
 OSPFv2 [RFC2328] prevents inter-area routes (which are learned from
 area 0) from being passed back to area 0.  However, GMPLS makes use
 of Type 10 (area-local scope) LSAs to propagate TE information
 [RFC3630], [RFC4202].  Type 10 Opaque LSAs are not flooded beyond the
 borders of their associated area.  It is therefore necessary to have
 a means by which Type 10 Opaque LSA may carry the information that a
 particular piece of routing information has been learned from a
 higher-level RC when propagated to a lower-level RC.  Any downward RC
 from this level, which receives an LSA with this information would
 omit the information in this LSA and thus not re-introduce this
 information back into a higher-level RC.

5.6. Routing Protocol Convergence

 Link state protocols have been designed to propagate detected
 topological changes (such as interface failures and link attributes
 modification).  The convergence period is short and involves a
 minimum of routing information exchange.
 Therefore, existing routing protocol convergence involves mechanisms
 that are sufficient for ASON applications.

Papadimitriou, et al. Informational [Page 10] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

5.7. Routing Information Scoping

 The routing protocol MUST support a single Ri advertising on behalf
 of more than one Li.  Since each Li is identified by a unique TE
 Router ID, the routing protocol MUST be able to advertise multiple TE
 Router IDs.  That is, for [RFC3630], multiple Router Addresses and
 for [RFC3784] multiple Traffic Engineering Router Ids.
 The Link sub-TLV that is currently part of the top level Link TLV
 associates the link to the Router_ID.  However, having the Ri
 advertising on behalf of multiple Lis creates the following issue, as
 there is no longer a 1:1 relationship between the Router_ID and the
 TE Router_ID, but a 1:N relationship is possible (see Section 5.1).
 As the link-local and link-remote (unnumbered) ID association may not
 be unique per abstract node (per Li unicity), the advertisement needs
 to indicate the remote Lj value and rely on the initial discovery
 process to retrieve the {Li;Lj} relationship(s).  In brief, as
 unnumbered links have their ID defined on per Li bases, the remote Lj
 needs to be identified to scope the link remote ID to the local Li.
 Therefore, the routing protocol MUST be able to disambiguate the
 advertised TE links so that they can be associated with the correct
 TE Router ID.
 Moreover, when the Ri advertises on behalf multiple Lis, the routing
 protocol MUST be able to disambiguate the advertised reachability
 information (see Section 5.3.3) so that it can be associated with the
 correct TE Router ID.

6. Evaluation Scenarios

 The evaluation scenarios are the following; they are respectively
 referred to as cases 1, 2, 3, and 4.
 In Figure 1, below,
  1. R3 represents an LSR with all components collocated.
  2. R2 shows how the "router" component may be disjoint from the node.
  3. R1 shows how a single "router" may manage multiple nodes.

Papadimitriou, et al. Informational [Page 11] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

  1. —————— ——-

|R1 | |R2 |

             |                   |   |       |    ------
             |  L1    L2    L3   |   |   L4  |   |R3    |
             |   :     :     :   |   |   :   |   |      |
             |   :     :     :   |   |   :   |   |  L5  |
 Control      ---+-----+-----+---     ---+---    |   :  |
 Plane           :     :     :           :       |   :  |
 ----------------+-----+-----+-----------+-------+---+--+-
 Data            :     :     :           :       |   :  |
 Plane          --     :    --          --       |  --  |
           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
                -- \   :  / --          --       |  --  |
                    \ -- /                       |      |
                     |P2|                         ------
                      --
              Figure 1.  Evaluation Cases 1, 2, and 3
 Case 1 as represented refers either to direct links between edges or
 to "logical links" as shown in Figure 2 (or any combination of them).
  1. —– ——

| | | |

                |  L1  |                      |  L2  |
                |  :   |                      |  :   |
                |  : R1|                      |  : R2|
 Control Plane   --+---                        --+---
 Elements          :                             :
 ------------------+-----------------------------+------------------
 Data Plane        :                             :
 Elements          :                             :
               ----+-----------------------------+-----
              |    :                             :     |
              |   ---            ---            ---    |
              |  |   |----------| P |----------|   |   |
           ---+--|   |           ---           |   |---+---
              |  |   |                         |   |   |
              |  | P1|-------------------------| P2|   |
              |   ---                           ---    |
               ----------------------------------------
                  Figure 2.  Case 1 with Logical Links
 Another case (referred to as Case 4) is constituted by the Abstract
 Node as represented in Figure 3.  There is no internal structure
 associated (externally) to the abstract node.

Papadimitriou, et al. Informational [Page 12] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

  1. ————-

|R4 |

                    |              |
                    |      L6      |
                    |       :      |
                    |    ......    |
                     ---:------:---
 Control Plane          :      :
                 +------+------+------+
 Data Plane             :      :
                     ---:------:---
                    |P8 :      :   |
                    |  --      --  |
                  --+-|P |----|P |-+--
                    |  --      --  |
                     --------------
                    Figure 3.  Case 4: Abstract Node
 Note: the "signaling function" referred to as Si, i.e., the control
 plane entity that processes the signaling messages, is not
 represented in these figures.

7. Summary of Necessary Additions to OSPF and IS-IS

 The following sections summarize the additions to be provided to OSPF
 and IS-IS in support of ASON routing.

7.1. OSPFv2

 Reachability      Extend Node Attribute sub-TLVs to support address
                   prefixes (see Section 5.3.3).
 Link Attributes   Representation of cross/inter-layer relationships
                   in link top-level link TLV (see Section 5.3.1).
                   Optionally, provide for per-signal-type bandwidth
                   accounting (see Section 5.3.1).
 Scoping           TE link advertisements to allow for retrieving
                   their respective local-remote TE Router_ID
                   relationship(s) (see Section 5.7).
                   Prefixes part of the reachability advertisement
                   (using Node Attribute top-level TLV) needs to be
                   associated to its respective local TE Router_ID
                   (see Section 5.7).

Papadimitriou, et al. Informational [Page 13] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Hierarchy         Provide a mechanism by which Type 10 Opaque LSA may
                   carry the information that a particular piece of
                   routing information has been learned from a
                   higher-level RC when propagated to a lower-level RC
                   (so as not to re-introduce this information into a
                   higher-level RC).

7.2. IS-IS

 Reachability      Provide for reachability advertisement (in the form
                   of reachable TE prefixes).
 Link Attributes   Representation of cross/inter-layer relationships
                   in Extended IS Reachability TLV (see Section
                   5.3.1).
                   Optionally, provide for per-signal-type bandwidth
                   accounting (see Section 5.3.1).
 Scoping           Extended IS Reachability TLVs to allow for
                   retrieving their respective local-remote TE
                   Router_ID relationship(s) (see Section 5.7).
                   Prefixes part of the reachability advertisement
                   needs to be associated to its respective local TE
                   Router_ID (see Section 5.7).
 Hierarchy         Extend the up/down bit mechanisms to propagate the
                   summarized topology (see Section 5.3) and traffic
                   engineering information as listed in Table 1, as
                   well as reachability information (see Section
                   5.3.3).

8. Security Considerations

 The introduction of a dynamic control plane to an ASON network
 exposes it to additional security risks that may have been controlled
 or limited by the use of management plane solutions.  The routing
 protocols play a part in the control plane and may be attacked so
 that they become unstable or provide incorrect information for use in
 path computation or by the signaling protocols.
 Nevertheless, there is no reason why the control plane components
 cannot be secured, and the security mechanisms developed for the
 routing protocol and used within the Internet are equally applicable
 within an ASON context.

Papadimitriou, et al. Informational [Page 14] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 [RFC4258] describes the requirements for security of routing
 protocols for the Automatically Switched Optical Network.  Reference
 is made to [M.3016], which lays out the overall security objectives
 of confidentiality, integrity, and accountability.  These are well
 discussed for the Internet routing protocols in [THREATS].
 A detailed discussion of routing threats and mechanisms that are
 currently deployed in operational networks to counter these threats
 is found in [OPSECPRACTICES].  A detailed listing of the device
 capabilities that can be used to support these practices can be found
 in [RFC3871].

9. Acknowledgements

 The authors would like to thank Adrian Farrel for having initiated
 the proposal of an ASON Routing Solution Design Team and the ITU-T
 SG15/Q14 for their careful review and input.

10. References

10.1. Normative References

 [RFC1195]         Callon, R., "Use of OSI IS-IS for routing in TCP/IP
                   and dual environments", RFC 1195, December 1990.
 [RFC2966]         Li, T., Przygienda, T., and H. Smit, "Domain-wide
                   Prefix Distribution with Two-Level IS-IS", RFC
                   2966, October 2000.
 [RFC2328]         Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                   1998.
 [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3477]         Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                   Links in Resource ReSerVation Protocol - Traffic
                   Engineering (RSVP-TE)", RFC 3477, January 2003.
 [RFC3630]         Katz, D., Kompella, K., and D. Yeung, "Traffic
                   Engineering (TE) Extensions to OSPF Version 2", RFC
                   3630, September 2003.
 [RFC3784]         Smit, H. and T. Li, "Intermediate System to
                   Intermediate System (IS-IS) Extensions for Traffic
                   Engineering (TE)", RFC 3784, June 2004.

Papadimitriou, et al. Informational [Page 15] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 [RFC3871]         Jones, G., Ed., "Operational Security Requirements
                   for Large Internet Service Provider (ISP) IP
                   Network Infrastructure", RFC 3871, September 2004.
 [RFC3946]         Mannie, E. and D. Papadimitriou, "Generalized
                   Multi-Protocol Label Switching (GMPLS) Extensions
                   for Synchronous Optical Network (SONET) and
                   Synchronous Digital Hierarchy (SDH) Control", RFC
                   3946, October 2004.
 [RFC4202]         Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
                   Extensions in Support of Generalized Multi-Protocol
                   Label Switching (GMPLS)", RFC 4202, October 2005.
 [RFC4203]         Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
                   Extensions in Support of Generalized Multi-Protocol
                   Label Switching (GMPLS)", RFC 4203, October 2005.
 [RFC4205]         Kompella, K., Ed., and Y. Rekhter, Ed.,
                   "Intermediate System to Intermediate System (IS-IS)
                   Extensions in Support of Generalized Multi-Protocol
                   Label Switching (GMPLS)", RFC 4205, October 2005.
 [RFC4258]         Brungard, D., "Requirements for Generalized Multi-
                   Protocol Label Switching (GMPLS) Routing for the
                   Automatically Switched Optical Network (ASON)", RFC
                   4258, November 2005.

10.2. Informative References

 [RFC4394]         Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
                   and D. Papadimitriou, "A Transport Network View of
                   the Link Management Protocol (LMP)", RFC 4394,
                   February 2006.
 [OPSECPRACTICES]  Kaeo, M., "Operational Security Current Practices",
                   Work in Progress, July 2006.
 [OSPF-NODE]       Aggarwal, R. and K. Kompella, "Advertising a
                   Router's Local Addresses in OSPF TE Extensions",
                   Work in Progress, June 2006.
 [THREATS]         Barbir, A., Murphy, S., and Y. Yang, "Generic
                   Threats to Routing Protocols", RFC 4593, October
                   2006.

Papadimitriou, et al. Informational [Page 16] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 For information on the availability of ITU Documents, please see
 http://www.itu.int
 [G.7715]          ITU-T Rec. G.7715/Y.1306, "Architecture and
                   Requirements for the Automatically Switched Optical
                   Network (ASON)", June 2002.
 [G.7715.1]        ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
                   Architecture and Requirements for Link State
                   Protocols", November 2003.
 [G.8080]          ITU-T Rec. G.8080/Y.1304, "Architecture for the
                   Automatically Switched Optical Network (ASON)",
                   June 2006.
 [M.3016]          ITU-T Rec. M.3016.0, "Security for the Management
                   Plane:  Overview", May 2005.

Papadimitriou, et al. Informational [Page 17] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

Appendix A. ASON Terminology

 This document makes use of the following terms:
 Administrative domain (see Recommendation G.805): For the purposes of
 [G.7715.1], an administrative domain represents the extent of
 resources that belong to a single player such as a network operator,
 a service provider, or an end-user.  Administrative domains of
 different players do not overlap amongst themselves.
 Control plane: Performs the call control and connection control
 functions.  Through signaling, the control plane sets up and releases
 connections and may restore a connection in case of a failure.
 (Control) Domain: Represents a collection of (control) entities that
 are grouped for a particular purpose.  The control plane is
 subdivided into domains matching administrative domains.  Within an
 administrative domain, further subdivisions of the control plane are
 recursively applied.  A routing control domain is an abstract entity
 that hides the details of the RC distribution.
 External NNI (E-NNI): Interfaces are located between protocol
 controllers between control domains.
 Internal NNI (I-NNI): Interfaces are located between protocol
 controllers within control domains.
 Link (see Recommendation G.805): A "topological component" that
 describes a fixed relationship between a "subnetwork" or "access
 group" and another "subnetwork" or "access group".  Links are not
 limited to being provided by a single server trail.
 Management plane: Performs management functions for the Transport
 Plane, the control plane, and the system as a whole.  It also
 provides coordination between all the planes.  The following
 management functional areas are performed in the management plane:
 performance, fault, configuration, accounting, and security
 management
 Management domain (see Recommendation G.805): A management domain
 defines a collection of managed objects that are grouped to meet
 organizational requirements according to geography, technology,
 policy, or other structure, and for a number of functional areas such
 as fault, configuration, accounting, performance, and security
 (FCAPS), for the purpose of providing control in a consistent manner.
 Management domains can be disjoint, contained, or overlapping.  As
 such, the resources within an administrative domain can be
 distributed into several possible overlapping management domains.

Papadimitriou, et al. Informational [Page 18] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 The same resource can therefore belong to several management domains
 simultaneously, but a management domain shall not cross the border of
 an administrative domain.
 Subnetwork Point (SNP): The SNP is a control plane abstraction that
 represents an actual or potential transport plane resource.  SNPs (in
 different subnetwork partitions) may represent the same transport
 resource.  A one-to-one correspondence should not be assumed.
 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
 for the purposes of routing.
 Termination Connection Point (TCP): A TCP represents the output of a
 Trail Termination function or the input to a Trail Termination Sink
 function.
 Transport plane: Provides bi-directional or unidirectional transfer
 of user information, from one location to another.  It can also
 provide transfer of some control and network management information.
 The Transport Plane is layered; it is equivalent to the Transport
 Network defined in G.805 Recommendation.
 User Network Interface (UNI): Interfaces are located between protocol
 controllers between a user and a control domain.  Note: There is no
 routing function associated with a UNI reference point.

Appendix B. ASON Routing Terminology

 This document makes use of the following terms:
 Routing Area (RA): An RA represents a partition of the data plane,
 and its identifier is used within the control plane as the
 representation of this partition.  Per [G.8080], an RA is defined by
 a set of sub-networks, the links that interconnect them, and the
 interfaces representing the ends of the links exiting that RA.  An RA
 may contain smaller RAs inter-connected by links.  The limit of
 subdivision results in an RA that contains two sub-networks
 interconnected by a single link.
 Routing Database (RDB): Repository for the local topology, network
 topology, reachability, and other routing information that is updated
 as part of the routing information exchange and that may additionally
 contain information that is configured.  The RDB may contain routing
 information for more than one Routing Area (RA).

Papadimitriou, et al. Informational [Page 19] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

 Routing Components: ASON routing architecture functions.  These
 functions can be classified as being protocol independent (Link
 Resource Manager or LRM, Routing Controller or RC) and protocol
 specific (Protocol Controller or PC).
 Routing Controller (RC): Handles (abstract) information needed for
 routing and the routing information exchange with peering RCs by
 operating on the RDB.  The RC has access to a view of the RDB.  The
 RC is protocol independent.
 Note: Since the RDB may contain routing information pertaining to
 multiple RAs (and possibly to multiple layer networks), the RCs
 accessing the RDB may share the routing information.
 Link Resource Manager (LRM): Supplies all the relevant component and
 TE link information to the RC.  It informs the RC about any state
 changes of the link resources it controls.
 Protocol Controller (PC): Handles protocol-specific message exchanges
 according to the reference point over which the information is
 exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC.
 The PC function is protocol dependent.

Papadimitriou, et al. Informational [Page 20] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

Authors' Addresses

 Dimitri Papadimitriou, Ed.
 Alcatel
 Francis Wellensplein 1,
 B-2018 Antwerpen, Belgium
 Phone: +32 3 2408491
 EMail: dimitri.papadimitriou@alcatel.be
 Lyndon Ong
 Ciena Corporation
 PO Box 308
 Cupertino, CA 95015 , USA
 Phone: +1 408 705 2978
 EMail: lyong@ciena.com
 Jonathan Sadler
 Tellabs
 1415 W. Diehl Rd
 Naperville, IL 60563
 EMail: jonathan.sadler@tellabs.com
 Stephen Shew
 Nortel Networks
 3500 Carling Ave.
 Ottawa, Ontario, CANADA K2H 8E9
 Phone: +1 613 7632462
 EMail: sdshew@nortel.com
 Dave Ward
 Cisco Systems
 170 W. Tasman Dr.
 San Jose, CA 95134 USA
 Phone: +1-408-526-4000
 EMail: dward@cisco.com

Papadimitriou, et al. Informational [Page 21] RFC 4652 Evaluation of Routing Protocols against ASON October 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Papadimitriou, et al. Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4652.txt · Last modified: 2006/10/27 18:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki