IETF Internet Draft T. Otani Proposed status: Informational M. Hayashi Expires: January 2005 KDDI R&D Labs S. Okamoto NTT July 2004 TE parameters to be exchanged between GMPLS-controlled ASes Document: draft-otani-ccamp-interas-gmpls-te-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. "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. Abstract This draft investigates the difference between MPLS Inter-AS traffic engineering (TE) and GMPLS Inter-AS TE and describes requirements of TE parameters to be dynamically or statically exchanged between Generalized Multiprotocol Label Switching (GMPLS) inter-ASes. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Conventions used in this document...............................3 3. Assumed network model...........................................3 T. Otani et al. Informational - Expires January 2005 1 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 4. Clarification of necessity of dynamic or static information exchange between GMPLS Inter ASes..................................5 5. Requirement of TE parameters to be supported for EGP............7 6. Security consideration..........................................8 7. Intellectual property considerations............................8 8. Normative references............................................8 Author's Addresses.................................................9 Document expiration................................................9 Copyright statement................................................9 T. Otani et al. Informational - Expires January 2005 2 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 1. Introduction Since basic sets of GMPLS protocols have been so far standardized, CCAMP WG proposed to start to discuss about MPLS/GMPLS inter-domain traffic engineering (TE) [Inter-domain]. To proceed with this work, scalability and operational efficiency considering an actual networking environment is quite significant. TE information exchanged over domains (areas or ASes) for controlling GMPLS Label Switched Paths (LSPs) is more stringent than that of MPLS LSPs [MPLS-AS] from the point of an effective operation, because in order to dynamically or statically establish GMPLS LSPs, the additional TE information to the conventional MPLS-TE must be considered to be exchanged, such as switching capability, bandwidth encoding, and so forth. This document describes the necessity of dynamic or static TE information exchange between GMPLS-controlled ASes as well as the requirement of TE parameters for this routing operation. 2. Conventions used in this document In this document the steps for walking a pull-down tree are indented on subsequent lines. This allows abbreviation rather than a barrage of 'then click' or 'select' strings in a paragraph form. Example: 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 [1]. 3. Assumed network model 3.1 GMPLS network model Here, we assumed the below network model consisting of two GMPLS ASes. Each GMPLS AS is connected via traffic engineering (TE) links with a certain value of bandwidth (bw is, for example, 2.5Gbit/s, 10Gbit/s, etc.) between different GMPLS AS boarder nodes (A3-B1 and A4-B2). Moreover, each nodes in both AS 1 and AS 2 support x and y switching capability (x or y means TDM, Lambda or lambda). The edge node of the network (possibly A1, A2, B3, B4) may have the switching capability of packet (psc). Moreover, each TE link has a z or w encoding type (z or w means SONET/SDH, Lambda, Ethernet, etc). | +-------+ z-enc. +-------+ z-enc. +-------+ z-enc. +-------+ |A1,x-SC|----//----|A3,x-SC|-----------|B1,y-SC|----//----|B3,y-SC| +-------+ bw-1 +-------+ bw-1 +-------+ bw-1 +-------+ | | | | | =bw-1 =bw-1 | =bw-1 =bw-1 T. Otani et al. Informational - Expires January 2005 3 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 |z-enc. |z-enc. | |z-enc. |z-enc. | | | | | +-------+ w-enc. +-------+ w-enc. +-------+ w-enc. +-------+ |A2,x-SC|----//----|A4,x-SC|-----------|B2,y-SC|----//----|B4,y-SC| +-------+ bw-2 +-------+ bw-2 +-------+ bw-2 +-------+ | GMPLS AS 1 | GMPLS AS 2 Figure 1: GMPLS Inter AS network model(1) Between GMPLS AS border nodes, the routing information is statically or dynamically exchanged. Link management protocol (LMP) [LMP] may be applied to maintain and manage TE links between GMPLS AS border nodes. In general, the attributes of two TE-Links (A1-B3 and A4-B2) between AS border nodes as well as switching capability of each border node shall not be always same. Therefore, GMPLS nodes shall identify the attributes of these TE-Links and border nodes in order to create LSP over multiple ASes. The conventional MPLS technology does not provide the functionality to discriminate such attributes. 3.2 MPLS network model In the conventional MPLS network, we can assume MPLS Inter AS network model as below. There are no routing constraints such as switching capability and encoding type, compared to the GMPLS Inter AS network model. All nodes have the same switching capability of packet. | +----+ +----+ | +----+ +----+ | A1 |----//----| A3 |---------| B1 |----//----| B3 | +----+ 2.5G +----+ 2.5G +----+ 2.5G +----+ | | | | | =2.5G =2.5G | =2.5G =2.5G | | | | | +----+ +----+ | +----+ +----+ | A2 |----//----| A4 |---------| B2 |----//----| B4 | +----+ 10G +----+ 10G +----+ 10G +----+ | MPLS AS 1 | MPLS AS 2 Figure 2: MPLS Inter AS network model In the following section, we consider a MPLS or GMPLS path setup from an edge node in AS 1 to an edge node in AS2. T. Otani et al. Informational - Expires January 2005 4 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 4. Clarification of necessity of dynamic or static information exchange between GMPLS Inter ASes 4.1 Interface Switching capability A constraint of bandwidth in GMPLS controlled network is different from that of IP/MPLS network. In Figure 2, two TE links with different values of bandwidth such as 2.5 Gbit/s and 10 Gbit/s are assumed. If an MPLS LSP with 2.5 Gbit/s bandwidth is established from A2 to B4 in Figure 2, two set of TE links (A2-A4-B2-B4 and A2- A1-A3-B1-B3-B4) can be selected. In the case of GMPLS inter ASes, the ingress node is beneficial to know switching capabilities supported in each AS when a route for a GMPLS-LSP across multiple ASes is computed. For a request of GMPLS- LSP setup, the ingress node determine the appropriate next-hop AS, which is capable of desired switching capability, if such information is exchanged between GMPLS ASes. Here, we assume a switching capability as Lambda and an encoding type as lambda, as shown in Figure 3. The bandwidth of each TE link is, for example, corresponding to the transponderÆs bit rate of each DWDM channel. As shown in Figure 3, a GMPLS LSP with 2.5 Gbit/s can not be established over a set of TE links (A2-A4-B2-B4) because all nodes support only LSC which can not deal with sub-rate switching and the 10 Gbit/s TE link can only support a GMPLS LSP with 10 Gbit/s. If multiple GMPLS routes exist for a destination in a different AS, a path should be selected satisfying these routing constraints, in addition to the conventional EGP attributes. Although an operator may want to specify the AS border node explicitly for such a destination, this TE information exchange will improve operational efficiency in GMPLS-controlled networks. Therefore, not only IGP [GMPLS-Routing] but also EGP should advertise this TE parameter. | +------+ 2.5G +------+ 2.5G +------+ 2.5G +------+ |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC| +------+ Lambda +------+ Lambda +------+ Lambda +------+ | | | | | 2.5G=Lambda 2.5G=Lambda | 2.5G=Lambda 2.5G=Lambda | | | | | +------+ 10G +------+ 10G +------+ 10G +------+ |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC| +------+ Lambda +------+ Lambda +------+ Lambda +------+ | GMPLS AS 1 | GMPLS AS 2 Figure 3: GMPLS Inter AS network model (2) T. Otani et al. Informational - Expires January 2005 5 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 4.2 Bandwidth The advertisement of the available bandwidth over GMPLS inter ASes is strongly dependent on the operational policy in each GMPLS ASes. The resource available for different ASes may be advertised over GMPLS inters ASes, although the actual bandwidth is more than that for different ASes. The GMPLS Border nodes have the functionality to control the advertised resource bandwidth reached to a destination. For example, even if 4 times OC-48 bandwidth exists to a destination in one GMPLS AS, the AS may advertise only twice OC-48 bandwidth to another GMPLS AS, following the mutual policy between these two ASes. 4.3 Encoding type Here, TE links with a different encoding type in a GMPLS Inter AS network are assumed as in Figure 3. In this case, differing from the case of a MPLS inter AS network, a GMPLS LSP with a specific encoding type must be established to satisfy this constraint. Since physical layer technologies used to form TE links limits the signal encoding type to be transported, the ingress node should consider this by obtaining TE parameters exchanged between GMPLS-controlled inter-ASes | +------+ +------+ | +------+ +------+ |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC| +------+ SONET +------+ SONET +------+ SONET +------+ | | | | | =SONET =SONET | =SONET =SONET | | | | | +------+ +------+ | +------+ +------+ |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC| +------+ lambda +------+ lambda +------+ lambda +------+ | GMPLS AS 1 | GMPLS AS 2 Figure 4: GMPLS Inter AS network model (3) 4.4 Mixed case Here, we consider a mixed case of 4.1, 4.2 and 4.3, and assume two ASes: AS 1 consisting of GMPLS nodes with LSC and TE links with Lambda encoding type at 2.5 Gbit/s, and AS 2 consisting of GMPLS nodes with TDM-SC and TE links with SONET/SDH encoding type at 10 Gbit/s. GMPLS nodes in AS 2 support sub-rate switching, for example, of 2.5 Gbit/s. | T. Otani et al. Informational - Expires January 2005 6 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 +------+ 2.5G +------+ 2.5G +------+ 10G +------+ |A1,LSC|----//----|A3,LSC|-----------|B1,TSC|----//----|B3,TSC| +------+ Lambda +------+ SONET +------+ SONET +------+ | | | | | 2.5G=Lambda 2.5G=Lambda | 10G=SONET 10G=SONET | | | | | +------+ 2.5G +------+ 10G +------+ 10G +------+ |A2,LSC|----//----|A4,LSC|-----------|B2,TSC|----//----|B4,TSC| +------+ Lambda +------+ SONET +------+ SONET +------+ | GMPLS AS 1 | GMPLS AS 2 Figure 5: GMPLS Inter AS network model (4) If a GMPLS LSP with 2.5 Gbit/s is established from A2 to B3, the ingress node should know not only the reachability of B3 in AS 2 but also the sub-rate (TDM) switching capability of nodes in AS 2 and available bandwidth to the destination. In this sense, an end-point (reachability) list consisting of node IDs, interface addresses, interface IDs per switching capability is very useful and may be advertised over GMPLS ASes. Operators may usually use a different switching capable nodes and different TE link with different encoding type and bandwidth, decided by their business strategy and such TE information exchange is expected to improve operational efficiency in GMPLS-controlled networks. 4.5 SRLG To configure a secondary LSP in addition to a primary LSP over multiple GMPLS ASes, Shared Risk Link Group (SRLG) parameter is very significant. By introducing this parameter, the source node can route these LSPs so as to across the different AS boarder node as well as satisfy a SRLG constraint. The SRLG over multiple ASes may be determined as a globally unique in order to guarantee the SRLG diversity. 5. Requirement of TE parameters to be supported for EGP Coinciding with MPLS Inter AS work, the TE parameters for GMPLS Inter AS is considered to be added. A GMPLS AS border node is required to announce the below parameters in terms of node IDs, interface addresses and interface IDs, of which reachability is advertised via EGP. (1) Interface switching capability (1-1)Bandwidth T. Otani et al. Informational - Expires January 2005 7 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 A. Total link bandwidth B. Max./Min. Reservable bandwidth C. Unreserved bandwidth (1-2)Switching capability: TDM, lambda, FSC (2) Bandwidth Encoding: Ethernet, SONET/SDH, Lambda (3) SRLG As mentioned in section 4.4, an end-point (reachability) list consisting of node IDs, interface addresses, interface IDs per switching capability is formed in order to be advertised over GMPLS ASes. 6. Security consideration Security consideration will be discussed in a future version. This requirement will not change the underlying security issues. 7. Intellectual property considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Normative references 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [Inter-domain] A. Farrel, et al, öA framework for inter-domain MPLS traffic engineeringö, draft-farrel-ccamp-inter- fomain-framework-00.txt, April 2004. [MPLS-AS] R. Zhan, et al, öMPLS Inter-AS Traffic Engineering requirementsö, draft-ietf-tewg-interas-mpls-te-req- 07.txt, June 2004 (work in progress). T. Otani et al. Informational - Expires January 2005 8 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004 [LMP] J. Lang, et al, öLink Management Protocol (LMP)ö, draft-ietf-lmp-10.txtö, October 2003. [GMPLS-Routing] K. Kompera, et al, öRouting Extensions in Support of Generalized Multi-Protocol Label Switchingö, draft- ietf-ccamp-gmpls-routing-09.txt, October 2003. Author's Addresses Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp Michiaki Hayashi KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7547 Saitama, 356-8502. Japan Email: mc-hayashi@kddilabs.jp Satoru Okamoto NTT Network Service System Laboratory 3-9-11 Midori-cho, Musashino-shi, Phone: +81-422-59-4353 Tokyo, 180-8585. Japan Email: okamoto.satoru@lab.ntt.co.jp Document expiration This document will be expired in January 2005, unless it is updated. Copyright statement "Copyright (C) The Internet Society (year). 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." T. Otani et al. Informational - Expires January 2005 9