Internet Draft Internet Engineering Task Group Jin Ho Hahm Internet-Draft ETRI Kwang-il Lee Expiration Date: January 2001 Mark Carson NIST July 2000 Control Mechanisms for Traffic Engineering in Optical Networks draft-hahm-te-optical-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract WDM-based optical networks are becoming the core networks of the Internet transport infrastructure because of the plentiful bandwidth capacity they offer and their potential for real-time provisioning of bandwidth on demand. This document proposes control mechanisms for traffic engineering (TE) in optical networking, especially focusing on the integration of the control planes of MPLS and WDM-based networks. First of all, this Hahm et al [Page 1] document draft-hahm-te-optical-00.txt July 2000 document describes the basic operation of optical crossconnects(OXCs). And, it introduces the concept of TE manager for the combined control between two domains. Next, it defines the control messages exchanged between network components such as OXCs, routers/LSRs, and the TE manager. It then introduces the three traffic engineering procedures of dynamic bandwidth provisioning, fast restoration, and withdrawal of deployed network resources. 1. Introduction With the advent of MPLS, traffic engineering in the Internet became feasible. Explicit routing, prioritization of packets, rerouting schemes, etc. are same useful capabilities for traffic engineering that MPLS provides[1][2]. However, because the MPLS operates with the fixed topology and bandwidth capacity of network, when the network suffers from insufficient bandwidth on the some links, the mere management of explicit L3 routing has the limitation to solve problems of bandwidth starvation. The eventual solution for traffic engineering must incorporate on-line/adaptive bandwidth provisioning based on the configurability of optical networks[3][4]. Currently, the Internet transport infrastructure is moving toward high-density WDM optical networks. With the development of controllable optical devices, switching of individual light frequencies (i.e. lambdas) begins to be possible. Based on this, the topology, and the bandwidth capacity of optical backbone networks can be managed adaptively according to L3 requirements. However, as of yet, the control plane specifications for optical networking, and the relation between the IP layer and optical transport layer, are not well defined. This document provides a framework of the operation of the control plane for optical networking, especially from the OXC view point. It also defines a set of commands for controlling OXC components. This document proposes control plane integration between OXCs, routers(mean LSRs after this), and the TE manager for achieving robust traffic engineering. We provide detailed schemes on how these elements may communicate and collaborate with each other. The most desired benefits of traffic engineering in optical networking are adaptive bandwidth provisioning and fast restoration. We show how these goals are achieved by combining the exchange of control data between the network components such as OXCs, routers, and the TE manager. Hahm et al [Page 2] draft-hahm-te-optical-00.txt July 2000 2. Integrated System Architecture with OXCs and routers Figure 1 shows the integrated system architecture of a router with an attached OXC. Conceptually, this architecture includes a router-only system having fixed links with other routers, or a WDM-based pure optical crossconnect switch. Based on this architecture, we can control dynamic link connection between arbitrary routers, and manage the bandwidth capacity of each link on demand. We will show how the bandwidth capacity and the topology of router-to-router links can be managed by controlling the OXC system. In the case of a router-only system without OXC, we can assume the OXC is not controllable, and therefore the router has fixed connections with adjacent routers. In the case of a pure OXC system without router, we consider only the dynamic connection with adjacent OXCs. Each component of the OXC and router, and their detailed functions will be explained below. Router +----------------------------------+ | | | | | Ip1 Ip2 Op1 Op2 | +----+-----+------------+-----+----+ | | | | +----+ +----+ +----+ +----+ +-| OE |-| OE |------| EO |-| EO |-+ | +----+ +----+ +----+ +----+ | | | | | | | Fi1 | | | | | | Fo1 ~~~~~~~~~~~ | o | | ~~~~~~~~~~~~~ L1 =============+ | | +================= L1 L2 -------------|-+ +----+ +----------------------- L2 L3 *************|********| LS |****************************** L3 ~~~~~~~~~~~ | +----+ +----+ ~~~~~~~~~~~~~ | +====================| LS |==+ | ~~~~~~~~~~~ +----+ +----+ | ~~~~~~~~~~~~~ L1 =================| LC |-------------+ +=============== L1 L2 -------------o +----+ +----+ +--------------------- L2 L3 **************************| LS |************************** L3 ~~~~~~~~~~~ +----+ ~~~~~~~~~~~~~ Fi2 | | Fo2 +----------------------------------+ OXC figure 1. integrated system architecture 2.1 OXC Hahm et al [Page 3] draft-hahm-te-optical-00.txt July 2000 2.1.1 Components of OXC OXC is a path-switching element which provides an optical transport connection. As shown in the figure, an OXC system is logically composed of multiple incoming lambdas(L1,L2,L3), which are multiplexed in incoming fibers(Fi1,Fi2), multiple outgoing lambdas(L1,L2,L3), which are multiplexed in outgoing fibers(Fo1,Fo2), lambda switches(LSs), lambda converters(LCs), optical-to-electric converters(OEs), and electric-to-optical converters(EOs). As used here, a "lambda" is a narrowly spaced wavelength optical signal, which is multiplexed with other lambdas onto an outgoing fiber, and which on receipt over an incoming fiber, is demultiplexed from its peers to extract the required signal. Each lambda has its own frequency or color. A "lambda switch" is an element that switches incoming lambdas to outgoing lambdas, where both lambdas have identical wavelength (the same color). When the colors of the two lambdas are different, it is necessary to convert one wavelength to another, so a "lambda converter" is used. Generally, lambda conversion is more difficult operation than lambda switching. And, LCs are less abundant resources than LSs. We assume LCs can work only within a limited operating range. This means an LC can make only certain color conversions and not others. LSs also are limited, in that they can switch some lambdas but not others, because of the different position of lambdas and LSs. Therefore, even if we have sufficient remaining lambdas, LSs, and LCs in OXC, we can encounter situations where it is impossible to switch or convert the specific lambdas with intention. During operation, certain incoming or outgoing lambdas may be not be assigned for actual data transfer. These lambdas are called "dark lambdas." Similarly, a fiber is called a "dark fiber" when it is not in use. See, incoming lambda L2 of incoming fiber Fi2 is a dark lambda. Only when incoming and outgoing lambdas are dark, they can be switched or converted, because otherwise the transit operation would inevitably bring about data loss in lambdas. In our model we assume the OXC can be directly attached to the router with the OE and EO interfaces. The OE converts the incoming optical signal to electrical data for use in the router. The EO in turn converts the electrical outgoing data from the router to an optical signal to convey onto the outgoing lambda. We assume each OXC is IP capable and can participate in IP based control protocols. We assume internal operation of OXC may be configured remotely through sending control commands to the OXC. Even though in general any external system could capable of communicating with the OXC, we will restrict our attention to an architecture in which a TE manager controls all the OXC functions. Hahm et al [Page 4] draft-hahm-te-optical-00.txt July 2000 Light signals on incoming fibers and each incoming lambda of each fiber are monitored continuously. In general, the disappearance of all light signals on a specific optical fiber implies the fiber has been disconnected or damaged. On the other hand, disappearance of the light signal of a single lambda implies the malfunction of an LS or LC. The detection of the disappearance of light signals is the basis of the restoration process. In general restoration can be processed in the IP layer as a MPLS function, or as an optical switching functions. 2.1.2 Control of the OXC The internal configuration of the OXC can be manipulated remotely by control messages[5] from the TE manager. In this section we outline the required types of control messages, arguments, their behavior, and possible responses. (1) Establish Connection This message makes a connection between an incoming lambda and an outgoing lambda. In order to escape the loss of data, both lambdas are recommended to be dark. The message contains arguments such as incoming fiber id, incoming lambda id, outgoing fiber id, outgoing lambda id, and the explicit LC or LS id. As mentioned above, even if the unused lambdas, LSs, and LCs exist in OXC, they may fail to compose the requested operation, so the remaining resources and the applicability of them should be considered together. Therefore, the explicit indication of the network resources as arguments is recommended. If this message executes without error, the OXC sends an ACK back to the TE manager containing the new connection ID. Since only the TE manager fully understands the pattern of resource consumption in the OXCs, after receiving ACK, the TE manager updates its table of resource availability for future use. If the OXC cannot execute this message properly, it replies with a NACK stating the reason to the TE manager. (2) Release Connection This message releases an existing connection between incoming and outgoing lambdas in an OXC. The message contains the connection id reported when the connection was established. If the message executes successfully, the OXC replies with an ACK to the TE manager. Then the OXC reclaims the released network resources, and the TE manager updates the table of the resource availability for future use. If there is no existing connection with the designated id or the Hahm et al [Page 5] draft-hahm-te-optical-00.txt July 2000 lambdas are currently in use for data transfer, or the OXC cannot release the connection for some other reason, the OXC replies with a NACK to the TE manager. (3) Attach Port This message connects a dark incoming lambda to an unused input port of the router, or an unused output port to a dark outgoing lambda. The message includes arguments such as incoming fiber id, incoming lambda id, and input port id; or output port id, outgoing fiber id, and outgoing lambda id, respectively. If this message executes successfully, the OXC replies with an ACK containing the new port connection id. If this message does not execute properly, the OXC replies with a NACK to the TE manager. (4) Detach Port This message releases the existing port connection between an incoming lambda and input port, or an output port and outgoing lambda. The message contains the port connection id. If this message executes successfully, the OXC replies with an ACK to TE manager. After execution, the OXC reclaims the released optical network resources for future use, and the TE manager updates the table of resource availability for future use. If there is no existing port connection with designated id or the lambdas are in use for data transfer currently, or the OXC cannot release the connection for some other reason, the OXC replies with a NACK to the TE manager. (5) Query This message is used to check whether or not the designated resources are available in the OXC. The message contains the list of desired resources as argument. If all designated resources are available, the OXC replies with an ACK to the TE manager. If any of the designated resources are unavailable, the OXC replies with a NACK containing the list of unavailable resources. This message is used to synchronize differences between the actual resource status in the OXC and the resource database in TE manger. (6) Alarm Unlike the previous messages, this message is issued from OXC to TE manager. This message is used to inform the emergency status of an OXC. When incoming fibers are cut off, OXC detect the loss of light signal and issues this alarm message. This message is also used to inform of accidents in incoming lambdas, which can occur through the malfunction of network Hahm et al [Page 6] draft-hahm-te-optical-00.txt July 2000 componenets transferring the light signal, such as the LS and LC. In addition to these exchanges, the OXC continuously monitors its components, and informs the TE manager of its status periodically. 2.2 Router/LSR The router has the same functions as a normal router except the neighbor routers can be changed by reconfiguring the operation of attached OXC. A router has a number of input and output ports, which are connected to OEs and EOs of the OXC below. Among the ports, some input or output ports are not connected to outgoing lambda or incoming lambda. These ports are called as "unused ports", used for future configuration. In the figure, Ip2 is not connected any lambda of OXC, which is unused port. The configuration of the ports is managed by the OXC operation underneath. Therefore, the router just receives the result of configuration in a passive manner. If it is assumed that the router is a label switching router (LSR), capable of performing traffic engineering functions. The router will broadcast its link state information by periodic flooding. Based on this information, other LSRs can calculate QoS- assured routes considering the remaining bandwidth of each link, and label space in the routers involved. When the LSR broadcasts its link state information to other routers by the flooding mechanism defined in OSPF-LSA or ISIS-LSA [6], the TE manager also receives the flooded information, and understands the operational status of the network. In general depending on the bandwidth capacity of the link, a router may have multiple lightpaths to the same adjacent router. These lightpaths may be differentiated as fully utilized lightpaths, less utilized lightpaths, and unused lightpaths. When it is necessary to release lightpaths to collect network resources, unused lightpaths can be released without affecting the operation of the network at all. 2.3 Relation between OXC and Router By manipulating the components of OXCs correctly, two routers can establish direct connections. A sequence of lambdas travelling through several OXCs offers a unidirctional lightpath. The components involved in the lightpath are the output port of the sending router, the EO of the sending OXC, the possibly LSs or LCs depending on the nature of the connection, the OE of the receiving OXC and the input port of the receiving router and the lambdas between them. In order to construct a lightpath without disturbing the existing IP level operation, the components involving the lightpath should be remained unused. Hahm et al [Page 7] draft-hahm-te-optical-00.txt July 2000 Router a Router e +------+ +------+ | OP | | IP | +---+--+ +--+---+ | | | | +--+-+ L1 +----+ L1 +----+ L2 +----+ L2 +-+--+ | EO |********| LS |********| LC |========| LS |========| OE | +----+ --> +----+ --> +----+ --> +----+ --> +----+ OXC a OXC b OXC c OXC d OXC e figure 2: lightpath and the link between two adjacent routers 3. Framework for Combined Traffic Engineering In this section, we describe how traffic engineering is performed by combining MPLS and OXC control functions. The figure below shows the control signal between network elements, which are composed of routers, OXCs, and the TE manager. For this combined traffic engineering framework, we introduce the concept of a TE manager, which supports the integration between the control plane of the MPLS domain and the control plane of the optical networking domain. The figure below shows the IP network comprising of the lightpaths delivered from OXCs. There are directly connected optical fiber between OXC a and OXC b, OCX b and OXC e, OXC b and OXC c, OXC c and OXC d, OXC e and OXC f, OXC c and OXC f. The series of characters (%, #, @, &, *) represent the lightpaths between routers, they also show how the routers are connected each other. As seen in the figure, the TE manger has two kinds of control channels, one of which is a channel with routers, and the other is a channel with OXCs. Hahm et al [Page 8] draft-hahm-te-optical-00.txt July 2000 +--------------+ | TE manager | +--------------+ ^ ^ | | | | +----------------+--|--------------------+ | | | | +-|----------------|--+--------------------|-+ | | | | | | | | | | | | Ra | | Rb | | Rc | | Rd +-------+ | | +--------+ | | +--------+ | | +-------+ | % # * |<-|-+->| * @ | | | | % & * |<--+-|-->| * @ # | +-%-#-*-+ | +-*----@-+ | | +--% &-*-+ | +-*-@ #-+ | % # * |<-+--->| * @ | | | | % & * |<----+-->| * @ # | | % # ************* @ | | | | % & *************** @ # | | % ################# @@@@@@@@@@@@@@@@@@@@@%@&@@@@@@@@@@@@@@@@@@ # | | %%%%%%%%%%%%%%%% ########################%#&#################### | +-------+ +%-------+ | | +--%-&---+ +-------+ OXC a % OXC b | | OXC c % & OXC d % | | % & % | | % & % Re | | Rf % & % +---- --+ | | +-----+ % & % | % & @ |<-+--|->| @ % | % & % +-%-& @-+ | +-@-%-+ % & % | % & @ |<----+->| @ % | % & %%%%% & @@@@@@@@@@@@@@ %%%%% & | &&&&&&&&&&&&&&&&&&&&&&&& +------+ +-----+ OXC e OXC f figure 3: control signal for the traffic engineering 3.1 Introduction to the concept of the TE manager We can assume dynamic optical routing in a centralized manner[7], or in a distributed manner. A centralized method implies that route computations are carried out in one place, and the control commands for routing are also issued from one place. In distributed routing, route computations and control are performed at every router or OXC. In general, centralized methods and distributed methods have their own merits and short comings. A centralized method permits simple control but does not provide scalability or robustness. On the other hand, the distributed method can be scalable in a sense, but may need to exchange much of their status information each other when the operation of one position strongly depends on the status of others. Because the lightpath assignment takes place much less frequently Hahm et al [Page 9] draft-hahm-te-optical-00.txt July 2000 than the label switched path routing, scalability is not such a critical issue in a optical routing. Furthermore, because individual optical route computations may have dependencies on each other, as each vie for the exclusive possession of resources, distributed routing is not a good choice for optical routing. We assume a centralized method for the following reasons: (1) the timing of lightpath provisioning can be managed because we can estimate the progress of bandwidth increases or decreases by analyzing the link state information, (2) if the TE manager can control each OXC directly the control mechanisms can be simplified, (3) if the TE manager knows the internal structure and resources of OXCs, and guesses which resources of OXCs will be consumed according to its control command, message exchanges for synchronization can be eliminated, (4) the TE manger can have much greater computational power than an individual router or OXC, sufficient to meet the needs of the entire network 3.2 The analysis of network status and corresponding TE functions As mentioned previously, the TE manager receives link state information. By analyzing the bandwidth utilization of each link, the TE manager can determine the network status, such as which links are approaching saturation, which links are rarely used, and where new links must be added for supporting traffic increases. Based on this analysis, the TE manager can then make decisions on how to reallocate the network. Particular cases include: (1) Excessive traffic increase in an existing link If the utilization of a link is approaching the starvation, the TE manager can react by increasing the bandwidth by configuring new lightpath(s) between the routers. (2) Excessive traffic decrease in an existing link If a link is becomes greatly underutilized, its surplus capacity can be released to enhance overall network utilization. This can be done by releasing unused lightpath(s) between the routers. The released resources are reclaimed, and can be assigned for newly created links or increase bandwidth capacity on existing links. (3) Excessive traffic increase between ingress and egress routers When data traffic between a pair of ingress and egress routers increases much and the traffic travels many hops, this situation can be relieved by inserting a direct lightpath between these two routers. By doing this, we gain several benefits such as (1) from the viewpoint of service quality, the decrement of hop counts reduces the possibility of congestion and time delay of data Hahm et al [Page 10] draft-hahm-te-optical-00.txt July 2000 traffic, (2) from the viewpoint of network resources, the decrement of the total number of routers involved in passing the data traffic saves network resources such as bandwidth, buffers and label space of IP network. 3.3 Control message interchange between network elements We design the traffic engineering functions of IP networking and those of optical networking in a single system. However, in some cases, as when the IP communication service operator and the optical networking service operator are different companies, these two traffic engineering functions can be divided. This section provides a framework for the control messages between elements of our architecture. 3.3.1 Routers -> TE Manager (1) Link State Information TE manager participates in OSPF/ISIS link state advertisements. 3.3.2 TE Manager -> Routers The messages issued from the TE manager to routers can be categorized as follows. Here, we simply show the abstract outline of messages. Because these messages are not defined yet as a standard, it must be developed for the operation. (1) Link Insertion This message is issued after creating a lightpath between two routers which had no direct link before. This message changes the existing IP network topology. (2) Link Deletion This message is issued after deleting the lightpath between two routers. After execution of this message, there remains no direct link between two routers. This message changes the existing IP network topology. (3) Bandwidth capacity increase This message is issued after creating an additional lightpath between two routers which already have a direct link. This message does not change the existing IP network topology. Hahm et al [Page 11] draft-hahm-te-optical-00.txt July 2000 (4) Bandwidth capacity decrease This message is issued after deleting a lightpath between two routers which still leaves a direct link between them. This message does not change the existing IP network topology. After receiving any of these messages, routers send link state information announcing the change of network resources. All these messages are exchanged with Link State Advertisement(LSA). 3.3.3 TE Manager -> OXCs The functions of these messages were explained in section 2. The messages of Link Insertion or Bandwidth Capacity Increase from TE manger to routers are implemented by combining Connection and Attach Port here. The message of Link Deletion or Bandwidth Capacity Decrease are implemented by combining Release Connection and Detach Port. After issuing these messages, the TE manager updates the usable resources. The functions of each message are explained briefly because they have been described in detail above. (1) Connect between incoming and outgoing lambda This message connects an incoming lambda and an outgoing lambda with a lambda switch or lambda converter. (2) Release connection This message releases an existing connection according to the connection id. (3) Attach port This message connects an incoming lambda of the OXC to an input port of the router. An optical-to-electrical conversion is needed for this processing. (4) Detach port This message detaches an output port of the router from an outgoing lambda of the OXC. An electrical-to-optical conversion is needed for this processing. (5) Query This message is used to confirm the resource availability of the OXC. Hahm et al [Page 12] draft-hahm-te-optical-00.txt July 2000 3.3.4 OXCs -> TE Manager The function of this message was described in section 2. After receiving this message, the TE manager updates the usable resources. (1) Alarm This message reports the OXC status to the TE manager. It can be used for the disconnection of fibers and lambdas. 4. Traffic Engineering Procedure This section shows essential procedures for traffic engineering, which are composed of the combination of messages between network elements mentioned above. These procedures are focused on the main goals of traffic engineering including (1) maximizing utilization, (2) provisioning of additional bandwidth capacity in a automatic manner, (3) restoration to cope with problems such as the disconnection of optical fibers or the malfunction of network devices. 4.1 Provisioning of Additional Bandwidth Capacity In spite of applying rerouting mechanisms to find additional bandwidth capacity in the MPLS environment, a QoS assured path may not be found. In this case, an additional lightpath can be inserted between routers. In particular, if there is massive bandwidth request, (e.g. 5 Gbps), it may well be impossible to assign this amount of bandwidth at the MPLS level. In this case, an exclusive lightpath between the two routers can be created during service time. (a) Ingress router sends the link state information by flooding (b) TE manager calculates new lightpath based on available optical resources (c) TE manager sends the commands to OXCs along the lightpath (d) TE manager updates its optical resource table reflecting the usage of resources (e) TE manager sends the new bandwidth increase or change of topology to the corresponding router (f) The router floods the new bandwidth resource information (or topology change) to every MPLS router (g) Every router updates its bandwidth resource table (h) Router computes QoS routes based the increased bandwidth capacity 4.2 Restoration Hahm et al [Page 13] draft-hahm-te-optical-00.txt July 2000 The link between two routers corresponds to a lightpath, which consists of a sequence of switched lambdas. Because each lambda lies between two adjacent OXCs, the disconnection of a lightpath means the disconnection of a specific lambda. Therefore, when a link is disconnected, the corresponding OXC reports the disconnection to the TE manager. Then TE manager calculates an alternative lightpath, and contacts the OXCs involved in creating the new lightpath. Because the input and output ports are not changed during the restoration process the MPLS network operation is not influenced from this restoration procedure. This procedure is described below. (a) OXC reports the disconnection of lambda to TE manager (b) TE manager calculates alternative lightpath considering available optical resources. The alternative lightpath maintains the input port of the sending router and output port of the receiving router (c) TE manager sends the control commands to the corresponding OXCs (d) TE manager updates its optical resource table reflecting the usage of resources (e) The data loss is recovered by retransmission MPLS links can be disconnected by physical damage to optical cable. A single optical cable has many optical fibers, and each optical fiber has many lambdas. Each lambda is involved in the individual connection between two MPLS routers. Therefore, the damage of optical cable may bring about the disconnection of thousand links in MPLS network. The calculation of alternative lightpaths, and the negotiation of new lightpaths with each OXC may be impossible in a short time. 4.3 Release of Surplus Bandwidth Capacity Traffic in the Internet tends to change hour by hour, and day by day. So, overdeployed bandwidth must be withdrawn when it is not used anymore. Any surplus lightpaths are released for future provisioning of bandwidth or restoration processing. Even if the link is still transfering traffic (at a low level), the release procedure against the link can be executed because the loaded traffic is negligible. In this case, the resident traffic is rerouted first, and the lightpath is released. The newly assigned route after the rerouting process may be longer than former path, but it may contribute to the enhancement of total network utilization. (a) TE finds that a certain lightpath is not used for a long time because many lightpaths are allocated between two routers (b) TE manager sends the control messages releasing the lightpath to each OXC involving the lightpath. These messages can be a release connection and detach port (c) TE sends the new bandwidth decrease or change of topology to the Hahm et al [Page 14] draft-hahm-te-optical-00.txt July 2000 corresponding router (d) The router MPLS TE Manager floods the Bandwidth Resource Information (or Topology Change) to every MPLS Router (e) Router computes QoS routes based the increased bandwidth 5. Summary In this document, we have outlined traffic engineering mechanisms that integrate the control planes of MPLS and the WDM-based optical networking domain. We discuss the enhancement of traffic engineering functionality by using dynamic manipulation of the optical network. In the future, we will describe the traffic engineering mechanisms in more detail, and develop optical routing algorithms, which can meet multiple constraints such as transmission delay (relative to the distance between OXCs), the availability of limited network resource (incoming and outgoing lambdas, lambda switches, lambda converters, and input and output ports). We will also focus on risk dispersion algorithms. Such algorithms will lower the probability of complete disconnection between two adjacent routers by ensuring that lightpaths not travel the same optical fiber or optical cable to the extent possible. Security Considerations It is of course essential to maintain secure communication between the OXCs and TE manager. However, this document does not address the detailed security consideration. It is reserved for future study. References: [1] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC- 2702, September 1999. [2] Bilel Jamoussi et al, "Constraint-Based LSP Setup using LDP," Internet Draft , Work in Progress, July 2000 [3] Daniel, O. Awduche, Yakov Rekhter, John Drake, Rob Coltun, "Multi-Protocol L ambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossco nnects," Internet Draft, Work in Progress, November 1999 [4] J. Luciani, B. Rajagopalan, D. Awduche, B. Jamoussi and B. Cain, "IP over Op tical Networks: A Framework," Internet Draft, Work in Progress, 2000 Hahm et al [Page 15] draft-hahm-te-optical-00.txt July 2000 [5] Avri Doria, Kenneth Sundell, "Requirements for adding Optical Switch Support to GSMP," Internet Draft, Work in Progress, March 2000 [6] R. Coltun, "The OSPF LSA Option," RFC 2370, July 1998 [7] Daniel O. Awduche, Angela Chiu, Anwar Elwalid, Indra Widjaja, Xipeng Xiao, " A Framework for Internet Traffic Engineering," Internet Draft, Work in Progress,May 2000 Acknowledge This work is a product of a joint project between ETRI (Electronics and Telecommunications Research Institute in Korea) and NIST (National Institute of Standards and Technology). Author's Address Jin Ho Hahm ETRI 820 West Diamond Avenue Gaithersburg, MD 20899 Phone: 301-975-8400 Email: hahm@antd.nist.gov Kwang-il Lee NIST 820 West Diamond Avenue Gaithersburg, MD 20899 Phone: 301-975-8428 Email: kilee@antd.nist.gov Mark Carson NIST 820 West Diamond Avenue Gaithersburg, MD 20899 Phone: 301-975-3694 Email: mark.carson@nist.gov Hahm et al [Page 16]