G. Newsome Internet Draft Lucent Technologies Expires June 2001 IP Traffic Engineering Actions resulting in Optical Layer connections 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. 1. Abstract The objective of this draft is to discuss methods for deciding that an IP network would be improved in some way by the addition of extra capacity, (provided by an underlying network). The draft concludes that the only reasonable way of doing this is the result of co-operation between routers, and that this co-operation leads to the need for standardization of this process. 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 [ ]. 3. Introduction IP networks built on the top of Optical Transport Networks (OTN) need the ability to dynamically establish IP links over the wavelength-routed optical paths. In the current IP networks, the selection and establishment of the IP links is done manually, and not as a part of the active network operation. As the network size grows Management Plane Requirements-Newsome November 2000 [Page 2] and the number of individual network elements increases, manual link selection and establishment is likely to be impractical, i.e. slow and faulty. Hence, it becomes more and more desirable to provide the IP links in an automatic (non-manual) manner, where the controlling of the connectivity and performance is the part of active network operation. [te-ip] has discussed several factors resulting from whether the optical layer connection is made between boundary routers within an autonomous system (IGP peering) or between boundary routers of different autonomous systems (eBGP peering). [te-ip] further assumes that a data driven approach from a single router is not appropriate. This draft will not elaborate on the first points, and will provide additional rational for the second conclusion. In addition we conclude that co-operation between routers is required and that this co-operation will need work on protocols. 4. Discussion There are two fundamentally different ways in which a new optical network connection could be used in an IP network. If we consider a router within the IP network, these two cases are 1) The new connection terminates on this router or 2) The new connection bypasses the router. Let us consider why we may wish to set up an new optical layer connection in the first place. A new connection represents additional capacity which is being added to the IP network. There are two possible reasons for doing this. The first is the case when an un-connected router is being added to the network. The second is when an element of the network is suffering from overload. This discussion will concentrate on the second case, the addition of extra capacity to reduce a network overload. As the network is composed of both routers and links, either of these elements can be overloaded. Routers can have insufficient capacity for the aggregate traffic flow on all links, while a particular link might have insufficient capacity for the total traffic between two routers. 4.1 Router overload In the case of router overload the only additional capacity that can be useful is a new connection which bypasses the overloaded router. Adding extra port capacity to an already overloaded router makes no sense. Establishing a new connection therefore requires co-operation between the neighbors of the overloaded router. This co-operation has two elements. The neighbor routers must have free ports on the optical network, and they must have free capacity. This results in a negotiation between the overloaded router and its neighbors, and this negotiation must take place between all parties which will be involved in the new connection. This means the router detecting the overload as well as the two routers which will be the end points of the new connection. This implies that a new protocol may be Management Plane Requirements-Newsome November 2000 [Page 3] required to handle this negotiation and simply adding new information to Link State Advertisements does not seem to be sufficient. 4.2 Link overload Similar arguments apply in the case of an overloaded link. While it is true that the source router can independently determine that an overload condition exists, it cannot unilaterally request that a new link be created without the agreement of the end points of this new link. The negotiation between both parties is therefore very similar as before. Both routers involved in the new link must have free ports on the optical layer, and both must agree that router capacity is available to handle the extra traffic that the new link will deliver. 4.3 Removing capacity While the discussion has concentrated on the issues involved in adding capacity to the network, a perhaps slightly more difficult problem is that of removing capacity when it is no longer economical. Using similar arguments, it is clear that this also requires co-operation between all involved parties to avoid the loss of substantial quantities of data which may be in transit when the decision to remove the link is made. 5. Detecting overload The previous discussion assumes that capacity will be added in response to network overloads, whereby overload is tacitly assumed to mean that some service parameter can no longer be met. But what might be construed as an overload, and how long does it take to detect? It is quite feasible to consider the optical layer to be operated in much the same way as "demand ppp" operates over POTS connections. The potential connection is known before hand as a result of provisioning. As soon as a single packet appears destined for the provisioned link, that packet is stored while the link is activated. Activation would involving dialing and establishing a connection with the remote end of the link. In the case of POTS, this takes several seconds. In the case of the optical layer, this may take several hundreds of milliseconds. Would this make sense for the high capacity connections provided by the optical layer. There are two cases of interest. The first case is when the "traffic" results in very few packets being sent. In this case a link connection supporting many Gb/sec is setup and the actual traffic sent is a few bytes. This leads to very low link efficiencies. In the second case, the first packet is the first of a stream of data arriving at the rate the optical layer link can support. Assuming that this link runs at 2.5Gb/sec and that it takes only 200mSec to set up the link, a buffer of about 60Mb is required to bridge the link setup time. This doesn't seem to be very practical either, and becomes even less practical as the link rate increases to 10Gb/sec. We conclude that setting up a link in response to detecting a single Management Plane Requirements-Newsome November 2000 [Page 4] packet is not practical. The same arguments apply to any situation requiring that the optical layer link is set up in immediate response to any single event. In this example, the event was the detection of a packet destined for a particular destination, but an event such as a buffer overflow would have the same results. It is therefore necessary to detect overloads over a larger time scale. Optical layer links are therefore set up in response to some set of integrated observations and they will improve the network performance at some future time. Some agent is therefore required to perform the integration and to estimate the effect on the rest of the network of adding this link capacity. [te-ip] suggests that instability can occur if care is not taken. It has been suggested that adding links on a "bypass" basis, when the added link is NOT advertised to the network as a whole, can be useful in controlling network stability. This also has relation to work in the ION (IP over NBMA links) Working Group in developing the NHRP protocol [rfc2332]. As we are discussing automation of the network as whole, all links need to be treated the same way. If we merely set up most of the network manually and operate a few links specially, we have not met the initial goal of increasing network autonomy. We must therefore concentrate on stabilizing the network while making capacity changes, and advertising those changes as they occur. 6. Conclusions The preceding discussion indicates why optical layer links cannot be set up in response to single detected events, and why setting up such a link requires co-operative behavior among the several parties involved with alleviating the congestion. This need for a management agent co-operating with other similar agents on different routers leads to the conclusion that protocols need to be developed (or extended) that will support the information necessary to enable the best use of the optical layer to be made. In order to do this, we need to develop an understanding of the information necessary to enable overloading and the effect of adding capacity to the network to be calculated. This work is an IP management activity. 7. References [te-ip] O. Duroyon et al. "Triggering and advertising lightpaths in an IP over optical network" draft-duroyon-te-ip-optical-00.txt, Internet Draft, July 2000 [rfc2332] J. Luciani, et. al., "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998. 8. Author's Addresses George Newsome Lucent Technologies Room 3C505 101 Crawfords Corner Rd Holmdel, NJ 07728 Tel: 732 949 0812 Management Plane Requirements-Newsome November 2000 [Page 5] Fax: 732 949 3210 Email: gnewsome@lucent.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Management Plane Requirements-Newsome November 2000