IETF Internet Draft T. Otani Proposed status: Informational KDDI R&D Labs Expires: May 2005 K. Kumaki KDDI S. Okamoto NTT Oct. 2004 GMPLS Inter-domain Traffic Engineering Requirements Document: draft-otani-ccamp-interas-GMPLS-TE-01.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 provides requirements for the support of generalized multi-protocol label switching (GMPLS) inter-domain traffic engineering (TE). Its main objective is to present the differences between MPLS inter-domain TE and GMPLS inter-domain TE. This draft covers not only GMPLS Inter-domain architecture but also functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 T. Otani et al. Informational - Expires January 2005 1 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 1. Introduction....................................................3 2. Conventions used in this document...............................3 3. Assumed network model...........................................3 4. Requirement of exchanging TE information across AS boundaries...6 5. Requirement for GMPLS Inter-AS TE signaling, routing and management.........................................................9 6. Security consideration.........................................13 7. Acknowledgement................................................13 8. Intellectual property considerations...........................13 9. Informative references.........................................13 Author's Addresses................................................14 Document expiration...............................................15 Copyright statement...............................................15 T. Otani et al. Informational - Expires January 2005 2 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 1. Introduction Initial efforts of MPLS/GMPLS traffic engineering mechanism were focused on solving the problem within an Autonomous System (AS). Service Providers have come up with requirements for extending TE mechanisms across the domains (ASes as well as areas) [Inter-domain]. It discusses requirements for inter-domain Traffic Engineering mechanism with focus on packet MPLS networks and GMPLS packet switch capable (hereinafter MPLS). This document complements [Inter-domain] by providing some consideration for non-packet switch capable GMPLS networks (hereinafter GMPLS) scalability and operational efficiency in such a networking environment. TE information exchanged over domains for signaling and routing GMPLS Label Switched Paths (LSPs) is more stringent than that of MPLS LSPs [MPLS-AS] from the point of an effective operation. This is because in order to dynamically or statically establish GMPLS LSPs, the additional TE information, e.g., interface switching capability, link encoding, protection, and so forth must be considered. Operators may usually use different switching capable nodes and TE links 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. In terms of signaling, GMPLS signaling must operate over multiple domains using exchanged TE information or a statistically configured AS route. This signaling request should take into account bi- directionality, switching capability, encoding type, SRLG, and protection attributes of the TE links spanned by the path, as well as LSP encoding type and switching type for the end points. Furthermore, GMPLS LSP nesting may be applicable at the GMPLS domain borders and should be considered accordingly. This document provides the requirements for the support of GMPLS inter-domain TE, investigates the necessity of dynamic or static TE information exchange between GMPLS-controlled domains and describes the TE link parameters for this routing operation. This document also outlines GMPLS Inter-domain architecture, and provides functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment. 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]. 3. Assumed network model 3.1 GMPLS Inter-AS network model T. Otani et al. Informational - Expires January 2005 3 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 Figure 1 depicts a typical network, consisting of several GMPLS ASes, assumed in this document. AS1, AS2, AS3 and AS4 have multiple GMPLS inter-AS connections, and AS5 has only one GMPLS inter-AS connection. These ASes are an example of domains used without losing generality, and may be replaced by words such as others defined in [inter-domain]. +---------+ +---------|GMPLS AS2|----------+ | +----+----+ | +----+----+ | +----+----+ +---------+ |GMPLS AS1| | |GMPLS AS4|---|GMPLS AS5| +----+----+ | +----+----+ +---------+ | +----+----+ | +---------|GMPLS AS3|----------+ +---------+ Figure 1: GMPLS Inter-AS network model Each AS is configured using various switching and link technologies defined in [Arch] and an end-to-end route needs to respect TE link attributes like multiplexing type, encoding type, etc., making the problem a bit different from the case of classical (packet) MPLS. In order to route from one GMPLS AS to another GMPLS AS appropriately, each AS needs to advertise additional TE information, while concealing its internal topology information. In addition, a signaling mechanism is required to specify a route consisting of multiple ASes, while respecting the end-pointÆs encoding, switching and payload type. Section 4 describes the TE link attributes that need to be exchanged across the AS boundary in detail. 3.2 Comparison between a GMPLS inter-AS and a MPLS inter-AS (1) GMPLS network model To investigate the difference between a GMPLS inter-AS and an MPLS inter-AS network, we assume the network model shown in Fig. 2. Without loss of generality, this network model consists of two GMPLS ASes. The GMPLS AS border routers (A3, A4, B1, B2) are connected via traffic engineering (TE) links (A3-B1 and A4-B2). These inter-AS TE links are assumed to have a certain amount of bandwidth (bw), e.g., 2.5Gbit/s, 10Gbit/s, etc. Moreover, each nodes in both AS 1 and AS 2 can support x and y switching capabilities (e.g., x or y means TDM, Lambda or fiber). The edge node of the network (possibly A1, A2, B3, and B4) may also have the switching capability of packet (PSC1-4). 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 +-------+ T. Otani et al. Informational - Expires January 2005 4 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 | | | | | =bw-1 =bw-1 | =bw-1 =bw-1 |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 2: 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 need to identify the attributes of these TE-Links and border nodes in order to create LSP over multiple ASes. At present, GMPLS/ MPLS technology does not provide the functionality to discriminate such attributes. Furthermore, these GMPLS specific requirements for inter-area/ AS traffic engineering are not described in [Inter-domain]. (2) MPLS network model In the packet MPLS network, we can assume the MPLS Inter-AS network model as shown in Figure 3. 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 3: MPLS Inter-AS network model In the following section, we consider an 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 5 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 4. Requirement of exchanging TE information across AS boundaries In this section, we describe the TE attributes that needs to be exchanged across the AS boundaries for computation of GMPLS Path. 4.1 Interface Switching Capability A constraint of bandwidth in a GMPLS controlled network is different from that in an IP/MPLS network. In Figure 3, two TE links with different values of bandwidth such as 2.5Gbit/s and 10Gbit/s are assumed. If an MPLS LSP with 2.5Gbit/s bandwidth is established from A2 to B4 in Figure 3, two sets of TE links (that is two possible paths) can be selected (A2-A4-B2-B4 and A2-A1-A3-B1-B3-B4). In the case of GMPLS inter-ASes, the ingress node needs to know the switching capabilities supported in each AS, while computing a route for a GMPLS-LSP across multiple ASes. If the switching capabilities are exchanged across the AS boundaries, the ingress node can determine the appropriate next-hop AS that is capable of supporting the requesting switching capability. In the example of Figure 4, we assume a switching capability as lambda and an encoding type as lambda. The bandwidth of each TE link is, for example, corresponding to the transponderÆs bit rate of each DWDM channel. In this case, both inter-AS links may be acceptable from A2 to B4 if only TE information within each AS is considered. However, a GMPLS LSP with 2.5Gbit/s bandwidth 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 10Gbit/s TE link can only support a GMPLS LSP with 10Gbit/s. The set of TE links (A2-A1-A3-B1-B3-B4) must be used instead so as to route it over the inter AS-link of A3-B1. If multiple GMPLS routes exist for a given destination via different ASes, 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 needs to advertise some TE parameters. | +------+ 2.5G +------+ 2.5G +------+ 2.5G +------+ |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC| +------+ Lambda +------+ Lambda +------+ Lambda +------+ | | | | | 2.5G=Lambda 2.5G=Lambda | 10G=Lambda 2.5G=Lambda | | | | | +------+ 10G +------+ 2.5G +------+ 10G +------+ |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC| +------+ Lambda +------+ Lambda +------+ Lambda +------+ T. Otani et al. Informational - Expires January 2005 6 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 | GMPLS AS 1 | GMPLS AS 2 Figure 4: GMPLS Inter-AS network model (2) 4.2 Bandwidth Policy The advertisement of the bandwidth for traversing non-local ASes is strongly dependent on the operational policy in each GMPLS AS. The resource available for different ASes may be advertised over GMPLS inter-ASes, although the actual local bandwidth is more than that for different ASes. The GMPLS Border nodes have the functionality to control the advertised resource bandwidth to reach 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. Thus, inter-AS reachability information needs to be enhanced to include bandwidth information. 4.3 Encoding type In addition of the link switching type, an end-to-end GMPLS LSP needs to have same encoding type at all intermediate hops. In this section, we discuss the need for exchanging link encoding types across the AS boundaries. The example depicted in Figure 5 is considered where TE links with a different encoding type in a GMPLS Inter-AS network are assumed. In this case, differing from the case of a packet 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 limit the signal encoding type to be transported, the ingress node should consider this by obtaining TE parameters exchanged between GMPLS-controlled inter-ASes. In this case, both inter-AS links may be acceptable for routing from A2 to B4 if only TE information within each AS is considered. The set of TE links (A2-A1- A3-B1-B3-B4) must be used instead so as to route over the inter AS- link of A3-B1, satisfying the constraint of the encoding type. Therefore, inter-AS reachability information needs to be enhanced to include encoding type information. | +------+ +------+ | +------+ +------+ |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC| +------+ SONET +------+ SONET +------+ SONET +------+ | | | | | =SONET =SONET | =lambda =SONET | | | | | +------+ +------+ | +------+ +------+ |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC| T. Otani et al. Informational - Expires January 2005 7 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 +------+ lambda +------+ SONET +------+ lambda +------+ | GMPLS AS 1 | GMPLS AS 2 Figure 5: GMPLS Inter-AS network model (3) 4.4 Hybrid case In Figure 6, we consider a mixed case of 4.1, 4.2 and 4.3, and assume two ASes: AS 1 consisting of GMPLS nodes with TDM-SC and TE links with SONET/SDH encoding type, and AS 2 consisting of GMPLS nodes with LSC and TE links with lambda encoding type. GMPLS nodes in AS 2 support sub-rate switching, for example, of 2.5Gbit/s. | +------+ 2.5G +------+ 2.5G +------+ 2.5G +------+ |A1,TSC|----//----|A3,TSC|-----------|B1,LSC|----//----|B3,LSC| +------+ SONET +------+ SONET +------+ Lambda +------+ | | | | | 2.5G=SONET 2.5G=SONET | 10G=Lambda 2.5G=Lambda | | | | | +------+ 10G +------+ 2.5G +------+ 10G +------+ |A2,TSC|----//----|A4,TSC|-----------|B2,LSC|----//----|B4,LSC| +------+ SONET +------+ SONET +------+ Lambda +------+ | GMPLS AS 1 | GMPLS AS 2 Figure 6: GMPLS Inter-AS network model (4) If a GMPLS LSP with 2.5Gbit/s is established from A2 to B4, the ingress node should know not only the reachability of B4 in AS 2 but also the switching capability of nodes in AS 2. In this case, both inter-AS links may be acceptable for routing from A2 to B4 if only TE information within each AS is considered. However, since the switching capability supported in each AS is different, the set of TE links (A2-A1-A3-B1-B3-B4) must be used so as to route over the inter AS-link of A3-B1. Therefore, 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. 4.5 SRLG To configure a secondary LSP in addition to a primary LSP over multiple GMPLS ASes, the parameter of Shared Risk Link Group (SRLG) is very significant. By introducing this parameter, the source node can route these LSPs so as to across the different AS border node as well as satisfy a SRLG constraint. Although this SRLG is supported T. Otani et al. Informational - Expires January 2005 8 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 and defined within an ASes, the mechanism to maintain consistency of SRLG must be considered in a GMPLS inter-domain TE environment. There are cases where two different SPs may be sharing the same fate (facility) for TE links within the ASes administrated by them. However, presently there is no mechanism to allow SRLG to have global significance; SRLG administration is completely up to interconnected SPs. In this document we identify that, in order to guarantee the SRLG diversity requirement, the SRLGs in an inter-domain TE environment are required to be globally unique. 4.6 Protection Type To guarantee the GMPLS LSP's resiliency over multiple GMPLS ASes, the protection type in each AS should be carefully selected so as to satisfy resilient requirement of the LSP as an end-to-end manner. This enables us to establish a LSP with a protection mechanism per AS-basis, such as link or node protection. Each GMPLS AS will provide a type of the protection to a destination within itself. Otherwise, an end-to-end recovery may be provided by calculating at the source node with the consideration of SRLG. As the same with SRLG case, protection type administration is also up to interconnected SPs. Therefore, inter-AS reachability information needs to be enhanced to include protection type information. 5. Requirement for GMPLS Inter-AS TE signaling, routing and management 5.1 EGP extensions for GMPLS In IP/MPLS networks, the EGP such as BGP-4 is well-defined and widely deployed. However, the need for EGP extension for MPLS TE does not exist at present. Nonetheless, EGP extensions are required to support multiple GMPLS ASes as well as for layer 1 VPN [L1VPN]. GMPLS extension for multi-AS TE is required for guaranteeing inter-AS GMPLS constraints, when attempts are made to establish GMPLS LSPs over multiple domains as discussed in section 4. The EGP scalability should be considered in designing GMPLS extensions to allow exchange of some TE information in addition to reachability information. Furthermore, the GMPLS EGP must be designed to achieve such operation that defects in an AS do not affect the scalability of the IGP in a different AS, although the GMPLS EGP must promptly advertise the failure within the AS, ensuring the GMPLS inter-AS connection establishment. The EGP extensions for GMPLS must basically follow the GMPLS architecture [Arch], including the support of its exchange over out of band control channel. T. Otani et al. Informational - Expires January 2005 9 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 The EGP must have the functionality to consider any policies for controlling TE routing information to be flooded, which will be defined between ASes on a business or operational strategy basis. This EGP routing policy should be able to be changed and configured on a per AS basis. This policy control especially in terms of switching capability may be applicable to the extensions of hierarchical routing. Each AS should control the advertisement of the switching capability or re-advertisement of received switching capability. 5.1.1 TE parameters to be supported in EGP Coinciding with MPLS Inter-AS work, the TE parameters for GMPLS Inter-AS are considered to be added. A GMPLS AS border node is required to announce the following 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 A. Total link bandwidth B. Max./Min. Reservable bandwidth C. Maximum LSP bandwidth D. minimum LSP Bandwidth C. Unreserved bandwidth (1-2)Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC (2) Bandwidth Encoding type: As defined in [RFC3471], e.g., Ethernet, SONET/SDH, Lambda. (3) SRLG (Global view) (4) Protection type 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. For stitched, nested and contiguous GMPLS LSPs over multiple domains, a GMPLS LSP created within an AS will be announced as a (transit) link resource exposed to different ASes with appropriate TE parameters, while concealing intermediate nodes or interface addresses. The GMPLS EGP must support this functionality and locally configure this on the AS border nodes. To ensure future interworking operation between GMPLS and MPLS, the GMPLS EGP should be also applicable to MPLS inter-AS TE (bandwidth) information exchange. 5.1.2 EGP redistribution requirement GMPLS EGP redistribution mechanisms within the domain should be provided in a scalable manner. These GMPLS EGP redistribution T. Otani et al. Informational - Expires January 2005 10 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 mechanisms must be designed to achieve such operation that a defect in an AS does not affect the scalability of IGP in a different AS, although the GMPLS EGP must promptly advertise the failure within the AS, ensuring the GMPLS inter-AS connection establishment. Mechanisms for redistributing GMPLS TE information within the GMPLS domain can be a path computation element (PCE), I-BGP session, or re- injection to IGP. Especially, it is useful to adopt GMPLS end-to-end basis path calculation. PCE based requirement may be incorporated with the PCE Architecture document [PCE]. 5.2 Requirement for GMPLS Inter-AS signaling for the support of TE GMPLS Inter-AS signaling must establish GMPLS LSPs over GMPLS multiple domains with a dynamic calculation of the AS route and GMPLS AS border nodes. It also must support to explicitly specify AS routes, AS border nodes and GMPLS nodes. Moreover, specifying loose GMPLS nodes including GMPLS AS border nodes must be supported in GMPLS signaling. The AS border node received GMPLS signaling message from a source node in a different AS should support recalculation mechanisms to specify the route within its domain, such as RSVP route expansion technique, followed by GMPLS Inter-AS path computation. 5.2.1 GMPLS per-AS basis path calculation support Firstly, GMPLS per-AS basis path calculation is described. In this path calculation model, a GMPLS LSP head-end specifies GMPLS AS border nodes as loose hops to tail-end statically or dynamically [Path-comp]. The route information may be learned from the GMPLS EGP. The source node also calculates the intermediate nodes to reach the selected egress AS border node. Once the GMPLS path message has traversed to the connecting AS border node in the adjacent AS, another path calculation is conducted, for example, by RSVP-TE expansion to reach its destination, otherwise to reach an egress border node transiting to another AS. This path calculation will not necessarily guarantee the AS path optimality. 5.2.2 GMPLS end-to-end basis path calculation support GMPLS end-to-end basis path calculation is indicated next. In this path calculation, the GMPLS LSP head-end specifies an AS path route (for example, AS1-AS2-AS4-AS5 in Figure 1) as well as the intermediate nodes to the egress AS border node in its belonging AS. The AS border node in an adjacent AS will determine intermediate nodes followed by the specified AS path route. This path calculation will guarantee the AS path optimality, however, not necessarily guarantee end-to-end path optimality. 5.2.3 Fast Recovery support T. Otani et al. Informational - Expires January 2005 11 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 Fast recovery operation based on the end-to-end [e2e] and segment [SEG-RECOVERY] based approach should be supported over multiple GMPLS domains, considering inter-AS link, SRLG and node diversity. These types of operation SHOULD interoperate with GMPLS intra-AS TE fast recovery mechanism. The AS border node may respond indicating a path setup error if it does not support the protection/restoration mechanism which is requested by the signaling messages generated from the source node in the different AS. Depending on the recovery mode, re-optimization or revertive operations should be supported. 5.2.4 Policy Control Depending on the policy between ASes, the AS border GMPLS nodes may reject GMPLS inter-AS signaling messages if the unapproved objects are included. 5.3 GMPLS Inter-domain TE Management 5.3.1 GMPLS Inter-domain TE Fault Management To maintain the control channel session as well as to provide fault isolation mechanism, link management mechanisms such as [LMP] should be applied to TE links between GMPLS AS border nodes. To validate LSPs created over multiple domains, a generic tunnel tracing protocol (GTTP) may be applied [GTTP]. 5.3.2 GMPLS Inter-AS TE MIB Requirements GMPLS inter-AS TE Management Information Bases must be supported to manage and configure GMPLS inter-AS TE in terms of GMPLS LSPs, routing, TE links and so forth. These MIBs should extend the existing series of MIBs [GMPLS-TEMIB] to accommodate following functionalities; - To manage GMPLS LSP characteristics at the tunnel head-end as well as any other points of the TE tunnel. - To include both IPv4/v6 and AS number, or only AS number in the subobjects of GMPLS RSVP ERO. A label may be included in it. The example of the object is as follows; EXPLICIT_ROUTE class object: Address1 (loose IPv4 address prefix,label, /AS1) Address2 (loose IPv4 address prefix,label, /AS1) AS2 (AS number) Address3 (loose IPv4 address prefix,label, /AS3) Address4 (loose IPv4 address prefix,label, /AS3)-destination Or T. Otani et al. Informational - Expires January 2005 12 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 Address1 (loose IPv4 address prefix,label, /AS1) Address2 (loose IPv4 address prefix,label, /AS1) Address3 (loose IPv4 address prefix,label, /AS2) Address4 (loose IPv4 address prefix,label, /AS2) Address5 (loose IPv4 address prefix,label, /AS3) Address6 (loose IPv4 address prefix,label, /AS3)-destination - Inclusion of recording subobjects such as interface IPv4/v6 addresses, AS number, a label, a node-id and so on in the RRO of the RESV message, considering the established policies between GMPLS ASes. 6. Security consideration GMPLS Inter-domain TE should be implemented under a certain security consideration such as authentication of signaling and routing on the control plane as well as a data plane itself. Indeed, this will not change the underlying security issues. 7. Acknowledgement The author would like to express the thanks to Noaki Yamanaka, Kohei Shiomoto, Wataru Imajuku, Michiaki Hayashi, Zafar Ali and Adrian Farrel for their comments. 8. 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. 9. Informative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. T. Otani et al. Informational - Expires January 2005 13 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 [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- 09.txt, September 2004 (work in progress). [LMP] J. P. Lang, et al, "Link Management Protocol (LMP)", draft-ietf-lmp-10.txtö, October 2003. [GMPLS-Routing] K. Kompella, et al, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft- ietf-ccamp-gmpls-routing-09.txt, October 2003. [L1VPN] T. Takeda, et al, "Framework for Layer 1 Virtual Private Networks", draft-takeda-l1vpn-framework- 01.txt, July 2004. [PCE] A. Farrel,et al, "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, September 2004. [Arch] E. Mannie, et al, "Generalized Multi-Protocol Label Switching Architecture", draft-ietf-ccamp-gmpls- architecture-07.txt, May, 2003. [Path-comp] J. P. Vasseur, et al, "Inter-domain Traffic Engineering LSP path computation methods", draft- vasseur-ccamp-inter-domain-path-comp-00.txt, July 2004. [GMPLS-ROUTING] K. Kompella, et al, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft- ietf-ccamp-gmpls-routing-09.txt. [e2e] J. P. Lang, et al, "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", draft-ietf-ccamp- gmpls-recovery-e2e-signaling-01.txt, May, 2004. [SEG-RECOVERY] L. Berger, et al, "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery-00.txt, March 2004. [GTTP] R. Bonica, et al, "Generic Tunnel Tracing Protocol (GTTP) Specification", draft-ietf-ccamp-tunproto- 01.txt, Sept. 2004. [GMPLS-TEMIB] T. Nadeau, et al, "Generalized Multi-Protocol Label Switching Traffic Engineering Management Information Base", draft-ietf-ccamp-gmpls-te-mib-06.txt, Oct 2004. 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 Kenji Kumaki KDDI Corporation GARDEN AIR TOWER,3-10-10,Iidabshi Phone: +81-3-6678-3103 Chiyoda-ku,Tokyo, 102-8460. Japan Email: ke-kumaki@kddi.com Satoru Okamoto T. Otani et al. Informational - Expires January 2005 14 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txtOctober 2004 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 May 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 15