RFC 3717 - IP over Optical Networks: A Framework

时间:2006-10-28 来源: 作者: 点击:
NetworkWorkingGroupB.Rajagopalan RequestforComments:3717Consultant Category:InformationalJ.Luciani MarconiCommunications D.Awduche MCI March2004 IPoverOpticalNetworks:AFramework StatusofthisMemo ThismemoprovidesinformationfortheInternetcommunity.Itdo
  Network Working Group                                     B. Rajagopalan
Request for Comments: 3717                                    Consultant
Category: Informational                                       J. Luciani
                                                  Marconi Communications
                                                              D. Awduche
                                                                     MCI
                                                              March 2004

                 IP over Optical Networks: A Framework

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 (2004).  All Rights Reserved.

Abstract

   The Internet transport infrastructure is moving towards a model of
   high-speed routers interconnected by optical core networks.  The
   architectural choices for the interaction between IP and optical
   network layers, specifically, the routing and signaling aspects, are
   maturing.  At the same time, a consensus has emerged in the industry
   on utilizing IP-based protocols for the optical control plane.  This
   document defines a framework for IP over Optical networks,
   considering both the IP-based control plane for optical networks as
   well as IP-optical network interactions (together referred to as "IP
   over optical networks").

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  4
   3.  The Network Model. . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.  Network Interconnection. . . . . . . . . . . . . . . . .  8
       3.2.  Control Structure. . . . . . . . . . . . . . . . . . . . 11
   4.  IP over Optical Service Models and Requirements. . . . . . . . 13
       4.1.  Domain Services Model. . . . . . . . . . . . . . . . . . 13
       4.2.  Unified Service Model. . . . . . . . . . . . . . . . . . 14
       4.3.  Which Service Model? . . . . . . . . . . . . . . . . . . 15
       4.4.  What are the Possible Services?. . . . . . . . . . . . . 16
   5.  IP transport over Optical Networks . . . . . . . . . . . . . . 16
       5.1.  Interconnection Models . . . . . . . . . . . . . . . . . 17
       5.2.  Routing Approaches . . . . . . . . . . . . . . . . . . . 18
       5.3.  Signaling-Related. . . . . . . . . . . . . . . . . . . . 21
       5.4.  End-to-End Protection Models . . . . . . . . . . . . . . 23
   6.  IP-based Optical Control Plane Issues. . . . . . . . . . . . . 25
       6.1.  Addressing . . . . . . . . . . . . . . . . . . . . . . . 25
       6.2.  Neighbor Discovery . . . . . . . . . . . . . . . . . . . 27
       6.3.  Topology Discovery . . . . . . . . . . . . . . . . . . . 28
       6.4.  Protection and Restoration Models. . . . . . . . . . . . 29
       6.5.  Route Computation. . . . . . . . . . . . . . . . . . . . 30
       6.6.  Signaling Issues . . . . . . . . . . . . . . . . . . . . 32
       6.7.  Optical Internetworking. . . . . . . . . . . . . . . . . 34
   7.  Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
       7.1.  WDM and TDM in the Same Network. . . . . . . . . . . . . 35
       7.2.  Wavelength Conversion. . . . . . . . . . . . . . . . . . 36
       7.3.  Service Provider Peering Points. . . . . . . . . . . . . 36
       7.4.  Rate of Lightpath Set-Up . . . . . . . . . . . . . . . . 36
       7.5.  Distributed vs. Centralized Provisioning . . . . . . . . 37
       7.6.  Optical Networks with Additional Configurable
             Components . . . . . . . . . . . . . . . . . . . . . . . 38
       7.7.  Optical Networks with Limited Wavelength Conversion
             Capability . . . . . . . . . . . . . . . . . . . . . . . 38
   8.  Evolution Path for IP over Optical Architecture. . . . . . . . 39
   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 41
       9.1.  General Security Aspects . . . . . . . . . . . . . . . . 42
       9.2.  Security Considerations for Protocol Mechanisms. . . . . 43
   10. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 44
   11. Informative References . . . . . . . . . . . . . . . . . . . . 44
   12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45
   13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
   14. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 47
   15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48

1.  Introduction

   Optical network technologies are evolving rapidly in terms of
   functions and capabilities.  The increasing importance of optical
   networks is evidenced by the copious amount of attention focused on
   IP over optical networks and related photonic and electronic
   interworking issues by all major network service providers,
   telecommunications equipment vendors, and standards organizations. In
   this regard, the term "optical network" is used generically in
   practice to refer to both SONET/SDH-based transport networks, as well
   as switched optical networks (including all-optical networks).

   It has been realized that optical networks must be survivable,
   flexible, and controllable.  There is, therefore, an ongoing trend to
   introduce intelligence in the control plane of optical networks to
   make them more versatile [1].  An essential attribute of intelligent
   optical networks is the capability to instantiate and route optical
   layer connections in real-time or near real-time, and to provide
   capabilities that enhance network survivability.  Furthermore, there
   is a need for multi-vendor optical network interoperability, when an
   optical network may consist of interconnected vendor-specific optical
   sub-networks.

   The optical network must also be versatile because some service
   providers may offer generic optical layer services that may not be
   client-specific.  It would therefore be necessary to have an optical
   network control plane that can handle such generic optical services.

   There is general consensus in the industry that the optical network
   control plane should utilize IP-based protocols for dynamic
   provisioning and restoration of optical channels within and across
   optical sub-networks.  This is based on the practical view that
   signaling and routing mechanisms developed for IP traffic engineering
   applications could be re-used in optical networks. Nevertheless, the
   issues and requirements that are specific to optical networking must
   be understood to suitably adopt and adapt the IP-based protocols.
   This is especially the case for restoration, and for routing and
   signaling in all-optical networks.  Also, there are different views
   on the model for interaction between the optical network and client
   networks, such as IP networks.  Reasonable architectural alternatives
   in this regard must be supported, with an understanding of their
   relative merits.

   Thus, there are two fundamental issues related to IP over optical
   networks.  The first is the adaptation and reuse of IP control plane
   protocols within the optical network control plane, irrespective of
   the types of digital clients that utilize the optical network.  The

   second is the transport of IP traffic through an optical network
   together with the control and coordination issues that arise
   therefrom.

   This document defines a framework for IP over optical networks
   covering the requirements and mechanisms for establishing an IP-
   centric optical control plane, and the architectural aspects of IP
   transport over optical networks.  In this regard, it is recognized
   that the specific capabilities required for IP over optical networks
   would depend on the services expected at the IP-optical interface as
   well as the optical sub-network interfaces.  Depending on the
   specific operational requirements, a progression of capabilities is
   possible, reflecting increasingly sophisticated interactions at these
   interfaces.  This document therefore advocates the definition of
   "capability sets" that define the evolution of functionality at the
   interfaces as more sophisticated operational requirements arise.

   This document is organized as follows.  In the next section,
   terminology covering some basic concepts related to this framework
   are described.  The definitions are specific to this framework and
   may have other connotations elsewhere.  In Section 3, the network
   model pertinent to this framework is described.  The service model
   and requirements for IP-optical, and multi-vendor optical
   internetworking are described in Section 4.  This section also
   considers some general requirements.  Section 5 considers the
   architectural models for IP-optical interworking, describing the
   relative merits of each model.  It should be noted that it is not the
   intent of this document to promote any particular model over the
   others.  However, particular aspects of the models that may make one
   approach more appropriate than another in certain circumstances are
   described.  Section 6 describes IP-centric control plane mechanisms
   for optical networks, covering signaling and routing issues in
   support of provisioning and restoration.  The approaches described in
   Section 5 and 6 range from the relatively simple to the
   sophisticated.  Section 7 describes a number of specialized issues in
   relation to IP over optical networks.  Section 8 describes a possible
   evolution path for IP over optical networking capabilities in terms
   of increasingly sophisticated functionality that may be supported as
   the need arises.  Section 9 considers security issues pertinent to
   this framework.  Finally, the summary and conclusion are presented in
   Section 10.

2.  Terminology and Concepts

   This section introduces  terminology pertinent to this framework and
   some related concepts.  The definitions are specific to this
   framework and may have other interpretations elsewhere.

   WDM

   Wavelength Division Multiplexing (WDM) is a technology that allows
   multiple optical signals operating at different wavelengths to be
   multiplexed onto a single optical fiber and transported in parallel
   through the fiber.  In general, each optical wavelength may carry
   digital client payloads at a different data rate (e.g., OC-3c, OC-
   12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
   Ethernet, ATM, etc.).  For example, there are many commercial WDM
   networks in existence today that support a mix of SONET signals
   operating at OC-48c (approximately 2.5 Gbps) and OC-192
   (approximately 10 Gbps) over a single optical fiber.  An optical
   system with WDM capability can achieve parallel transmission of
   multiple wavelengths gracefully while maintaining high system
   performance and reliability.  In the near future, commercial dense
   WDM systems are expected to concurrently carry more than 160
   wavelengths at data rates of OC-192c and above, for a total of 1.6
   Tbps or more.  The term WDM will be used in this document to refer to
   both WDM and DWDM (Dense WDM).

   In general, it is worth noting that WDM links are affected by the
   following factors, which may introduce impairments into the optical
   signal path:

   1. The number of wavelengths on a single fiber.
   2. The serial bit rate per wavelength.
   3. The type of fiber.
   4. The amplification mechanism.
   5. The number and type of nodes through which the signals pass before
      reaching the egress node or before regeneration.

   All these factors (and others not mentioned here) constitute domain
   specific features of optical transport networks.  As noted in [1],
   these features should be taken into account in developing standards
   based solutions for IP over optical networks.

   Optical cross-connect (OXC)

   An OXC is a space-division switch that can switch an optical data
   stream from an input port to a output port.  Such a switch may
   utilize optical-electrical conversion at the input port and
   electrical-optical conversion at the output port, or it may be all-
   optical.  An OXC is assumed to have a control-plane processor that
   implements the signaling and routing protocols necessary for
   computing and instantiating optical channel connectivity in the
   optical domain.

   Optical channel trail or Lightpath

   An optical channel trail is a point-to-point optical layer connection
   between two access points in an optical network.  In this document,
   the term "lightpath" is used interchangeably with optical channel
   trail.

   Optical mesh sub-network

   An optical sub-network, as used in this framework, is a network of
   OXCs that supports end-to-end networking of optical channel trails
   providing functionality like routing, monitoring, grooming, and
   protection and restoration of optical channels.  The interconnection
   of OXCs in this network can be based on a general mesh topology. The
   following sub-layers may be associated with this network:

   (a) An optical multiplex section (OMS) layer network: The optical
       multiplex section layer provides transport for the optical
       channels.  The information contained in this layer is a data
       stream comprising a set of  optical channels, which may have a
       defined aggregate bandwidth.

   (b) An optical transmission section (OTS) layer network: This layer
       provides functionality for transmission of optical signals
       through different types of optical media.

   This framework does not address the interaction between the optical
   sub-network and the OMS, or between the OMS and OTS layer networks.

   Mesh optical network (or simply, "optical network")

   A mesh optical network, as used in document, is a topologically
   connected collection of optical sub-networks whose node degree may
   exceed 2.  Such an optical network is assumed to be under the purview
   of a single administrative entity.  It is also possible to conceive
   of a large scale global mesh optical network consisting of the
   voluntary interconnection of autonomous optical networks, each of
   which is owned and administered by an independent entity.  In such an
   environment, abstraction can be used to hide the internal details of
   each autonomous optical cloud from external clouds.

   Optical internetwork

   An optical internetwork is a mesh-connected collection of optical
   networks.  Each of these networks may be under a different
   administration.

   Wavelength continuity property

   A lightpath is said to satisfy the wavelength continuity property if
   it is transported over the same wavelength end-to-end.  Wavelength
   continuity is required in optical  networks with no wavelength
   conversion feature.

   Wavelength path

   A lightpath that satisfies the wavelength continuity property is
   called a wavelength path.

   Opaque vs. transparent optical networks

   A transparent optical network is an optical network in which optical
   signals are transported from transmitter to receiver entirely in the
   optical domain without OEO conversion.  Generally, intermediate
   switching nodes in a transparent optical network do not have access
   to the payload carried by the optical signals.

   Note that amplification  of signals at transit nodes is permitted in
   transparent optical networks (e.g., using Erbium Doped Fiber
   Amplifiers << EDFAs).

   On the other hand, in opaque optical networks,  transit nodes may
   manipulate  optical signals traversing through them.  An example of
   such manipulation would be OEO conversion which may involve 3R
   operations (reshaping, retiming, regeneration, and perhaps
   amplification).

   Trust domain

   A trust domain is a network under a single technical administration
   in which adequate security measures are established to prevent
   unauthorized intrusion from outside the domain.  Hence, it may be
   assumed that most nodes in the domain are deemed to be secure or
   trusted in some fashion.  Generally, the rule for "single"
   administrative control over a trust domain may be relaxed in practice
   if a set of administrative entities agree to trust one another to
   form an enlarged heterogeneous trust domain.  However, to simplify
   the discussions in this document, it will be assumed, without loss of
   generality, that the term trust domain applies to a single
   administrative entity with appropriate security policies.  It should
   be noted that within a trust domain, any subverted node can send
   control messages which can compromise the entire network.

   Flow

   In this document, the term flow will be used to signify the smallest
   non-separable stream of data, from the point of view of an endpoint
   or termination point (source or destination node).  The reader should
   note that the term flow is heavily overloaded in contemporary
   networking literature.  In this document, we will consider a
   wavelength to be a flow, under certain circumstances.  However, if
   there is a method to partition the bandwidth of the wavelength, then
   each partition may be considered a flow, for example using time
   division multiplexing (TDM), it may be feasible to consider each
   quanta of time within a given wavelength as a flow.

   Traffic Trunk

   A traffic trunk is an abstraction of traffic flow traversing the same
   path between two access points which allows some characteristics and
   attributes of the traffic to be parameterized.

3.  The Network Model

3.1.  Network Interconnection

   The network model considered in this memo consists of IP routers
   attached to an optical core internetwork, and connected to their
   peers over dynamically established switched optical channels.  The
   optical core itself is assumed to be incapable of processing
   individual IP packets in the data plane.

   The optical internetwork is assumed to consist of multiple optical
   networks, each of which may be administered by a different entity.
   Each optical network consists of sub-networks interconnected by
   optical fiber links in a general topology (referred to as an optical
   mesh network).  This network may contain re-configurable optical
   equipment from a single vendor or from multiple vendors.  In the near
   term, it may be expected that each sub-network will consist of
   switches from a single vendor.  In the future, as standardization
   efforts mature, each optical sub-network may in fact contain optical
   switches from different vendors.  In any case, each sub-network
   itself is assumed to be mesh-connected internally.  In general, it
   can be expected that topologically adjacent OXCs in an optical mesh
   network will be connected via multiple, parallel (bi-directional)
   optical links.  This network model is shown in Figure 1.

   In this environment, an optical sub-network may consist entirely of
   all-optical OXCs or OXCs with optical-electrical-optical (OEO)
   conversion.  Interconnection between sub-networks is assumed to be
   implemented through compatible physical interfaces, with suitable

   optical-electrical conversions where necessary.  The routers that
   have direct physical connectivity with the optical network are
   referred to as "edge routers" with respect to the optical network. As
   shown in Figure 1, other client networks (e.g., ATM) may also connect
   to the optical network.

   The switching function in an OXC is controlled by appropriately
   configuring the cross-connect fabric.  Conceptually, this may be
   viewed as setting up a cross-connect table whose entries are of the
   form <input port i, output port j>, indicating that the data stream
   entering input port i will be switched to output port j.  In the
   context of a wavelength selective cross-connect (generally referred
   to as a WXC), the cross-connect tables may also indicate the input
   and output wavelengths along with the input and output ports.  A
   lightpath from an ingress port in an OXC to an egress port in a
   remote OXC is established by setting up suitable cross-connects in
   the ingress, the egress and a set of intermediate OXCs such that a
   continuous physical path exists from the ingress to the egress port.
   Optical paths tend  to be bi-directional, i.e., the return path from
   the egress port to the ingress port is typically routed along the
   same set of intermediate interface cards as the forward path, but
   this may not be the case under all circumstances.

                           Optical Network
                   +---------------------------------------+
                   |                                       |
                   |          Optical Subnetwork           |
   +---------+     | +-----------------------------------+ |
   |         |     | | +-----+      +-----+      +-----+ | |
   | IP      |     | | |     |      |     |      |     | | |
   | Network +-UNI --+-+ OXC +------+ OXC +------+ OXC + | |
   |         |     | | |     |      |     |      |     | | |
   +---------+     | | +--+--+      +--+--+      +--+--+ | |
                   | +----|------------|------------|----+ |
                   |      |            |            |      |
                   |     INNI         INNI         INNI    |
   +---------+     |      |            |            |      |
   |         |     | +----+------+     |    +-------+----+ |
   | IP      + UNI-  |           |  +-----+ |            | |
   | Network |     | |  Optical  |          |   Optical  | |
   |         |     | |Subnetwork +---INNI---+ Subnetwork | |
   +---------+     | |           |          |            | |
                   | +-----+-----+          +------+-----+ |
                   |       |                       |       |
                   +-------+-----------------------+-------+
                           |                       |
                          ENNI                    ENNI
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容