Internet DRAFT - draft-otani-ccamp-inter-domain-routing-req

draft-otani-ccamp-inter-domain-routing-req




               IETF Internet Draft                                            T. Otani 
               Proposed status: Informational                            KDDI R&D Labs 
               Expires:April 2006                                           S. Okamoto 
                                                                                   NTT 
                                                                          October 2005 
                
                
                      GMPLS Inter-domain routing problem statement and requirements 
                
                       Document: draft-otani-ccamp-inter-domain-routing-req-00.txt 
                   
                   
                   
               Status of this Memo 
                
                  By submitting this Internet-Draft, each author represents that any 
                  applicable patent or other IPR claims of which he or she is aware 
                  have been or will be disclosed, and any of which he or she becomes 
                  aware will be disclosed, in accordance with Section 6 of BCP 79. 
                
                  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 problem statement and requirements of inter-
                  domain routing in a generalized multi-protocol label switching 
                  (GMPLS) network. The reachability information exchange must be 
                  supported for appropriate signaling operation in a GMPLS network, as 
                  the same with the IP/MPLS inter-domain case. 
                
               Table of Contents 
                   
                  Status of this Memo................................................1 
                  Abstract...........................................................1 
                  1. Introduction....................................................3 
                  2. Conventions used in this document...............................3 
                  3. Problems statement of GMPLS inter-domain networks...............3 
                  4. Requirement of GMPLS inter-domain routing.......................4 
                  6. Security consideration..........................................6 
                  7. Acknowledgement.................................................6 
                    
                  T. Otani et al.  Informational - Expires April 2006               1 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
                  8. Intellectual property considerations............................6 
                  9. Informative references..........................................6 
                  Author's Addresses.................................................7 
                  Document expiration................................................7 
                  Copyright statement................................................7 
                    
                  T. Otani et al.  Informational - Expires April 2006               2 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
               1. Introduction 
                   
                  Initial efforts of GMPLS functions were focused on solving the 
                  problem within an Autonomous System (AS) or area (hereinafter domain). 
                  Service Providers (SPs) are getting to come up with difficulties to 
                  design future GMPLS networks considering multi-domain extensions due 
                  to no definition of inter-domain routing.  Although documents of 
                  inter-domain framework [Inter-domain] as well as inter-domain TE 
                  requirements [Interas-te] touch upon the GMPLS inter-domain routing 
                  architecture, there is no clear definition of GMPLS inter-domain 
                  routing. Moreover, GMPLS inter-domain signaling is specifically 
                  defined [Inter-signaling] assuming that the reachability information 
                  is ensured between domains. On the other hand, standard organization 
                  (SDOs) such as ITU-T and OIF have already define the same 
                  functionality of iter-domain routing as E-NNI functional 
                  specifications [ASON routing, OIF-ENNI]. 
                   
                  At this moment, SPs who want to utilize IETF GMPLS network can not 
                  imagine inter-domain GMPLS networks for inter-SPs as well as intra-SP 
                  but only intra-domain GMPLS networks, while other SDOs support such 
                  specifications. 
                   
                  If the MPLS world is looked at, the inter-domain requirements 
                  [RFC4105] are assumed under the condition of routing information 
                  exchange by BGP-4 between inter-domains.   
                   
                  [Interas-te] describes the requirements for extending TE mechanisms 
                  across the GMPLS network domains. However, before considering such 
                  requirements, the basic inter-domain routing requirement must be 
                  discussed and assessed among the working group members in order to 
                  assist appropriate GMPLS inter-domain signaling functionalities. 
                   
                  This document provides the problem statement in order to achieve 
                  GMPLS inter-domain networks especially in inter-SP operational 
                  environment.  It also proposes to specify the functional requirements 
                  to support of GMPLS inter-domain routing functions. 
                   
                   
               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. Problems statement of GMPLS inter-domain networks 
                   
                  Figure 1 depicts a typical network, consisting of several GMPLS 
                  domains, assumed in this document. D1, D2, D3 and D4 have multiple 
                  GMPLS inter-domain connections, and D5 has only one GMPLS inter-
                  domain connection. These domains follow the definition in [inter-
                  domain]. 
                   
                   
                    
                  T. Otani et al.  Informational - Expires April 2006               3 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
                                    +---------+ 
                          +---------|GMPLS  D2|----------+ 
                          |         +----+----+          | 
                     +----+----+         |          +----+----+   +---------+ 
                     |GMPLS  D1|         |          |GMPLS  D4|---|GMPLS  D5| 
                     +----+----+         |          +----+----+   +---------+ 
                          |         +----+----+          | 
                          +---------|GMPLS  D3|----------+ 
                                    +---------+ 
                   
                                Figure 1: GMPLS Inter-domain network model 
                   
                   
                  Each domain 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 domain to another 
                  GMPLS domain appropriately, each domain should advertise at least 
                  reachability information, while concealing its internal topology 
                  information through GMPLS exterior routing protocol, which has not 
                  yet been defined. Additional TE information may be required in the 
                  future, in order to improve the network control and management. 
                   
                  A signaling mechanism is required to specify a route consisting of 
                  multiple domains. [ID-sig] defines the signaling mechanisms over 
                  multiple domains, for example, to use loose hop expansion at the 
                  domain border routers.  It is quite difficult and less efficient from 
                  the point of operation to set up the route without knowing 
                  reachability information.  In such a case, the operator must specify 
                  the static route to the border node as well as appropriate border 
                  node, although the crank back mechanism may solve this issue (if we 
                  accept the possibility of multiple signaling tries). 
                   
                  In the IP/MPLS network, network nodes are only a packet switched 
                  device.  On the other hand, since the GMPLS network consists of 
                  various devices such as optical cross-connect equipment, IP/MPLS 
                  router, SDH-XC, and so forth, LSP end-point information may be useful 
                  in order to use a forwarding adjacency as inter-domain routing 
                  information. 
                   
                  Therefore, without sacrificing the operational efficiency as the same 
                  with MPLS inter-domain network, the clear definition of GMPLS inter-
                  domain routing must be defined for SPs who think about adopting the 
                  GMPLS technology to control their optical networks. 
                   
                   
               4. Requirement of GMPLS inter-domain routing 
                
                  In this section, we describe the requirements of GMPLS inter-domain 
                  routing for the computation of GMPLS paths over multiple domains. 
                
                  In IP/MPLS networks, inter-AS routing is assumed to reuse the 
                  existing EGP of BGP-4 and such architecture is widely established. 
                    
                  T. Otani et al.  Informational - Expires April 2006               4 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
                  However, such inter-domain routing has not been clearly defined so 
                  far for GMPLS inter-domain networks, even if it may be a straight 
                  forward to reuse the same protocol as IP/MPLS networks. 
                   
                  Therefore, inter-domain routing is required to support multiple GMPLS 
                  domains. 
                   
                  5.2.1 Reachability information exchange 
                   
                  GMPLS inter-domain routing mechanism must support the exchange of 
                  reachability information over each domain.  Reachability information 
                  includes: 
                        
                       (1) Reachable IP address (Node ID or Interface IP address) 
                       (2) Interface ID (unnumbered link) 
                   
                  The reachability information must be advertised in accordance with 
                  their belonging domain information in order to calculate the GMPLS 
                  LSP over multiple domains [id-sig].  The reachability information may 
                  be aggregated depending on the domain’s policy. 
                   
                  The scalability of inter-domain routing should be considered in 
                  designing future GMPLS extensions to allow exchange of TE information 
                  in addition to the above reachability information. Furthermore, the 
                  GMPLS inter-domain routing should be designed to achieve such 
                  operation that defects in one domain do not affect the scalability of 
                  an intra-domain routing of IGPs in other domains, although the GMPLS 
                  inter-domain routing should promptly advertise the failure within the 
                  domain, ensuring the GMPLS inter-domain connection establishment. 
                   
                  The GMPLS network, in general, consists of various devices such as 
                  optical cross-connect equipment, IP/MPLS router, SDH-XC, and so forth, 
                  and LSP end-point information should be useful in order to use a 
                  forwarding adjacency as inter-domain routing information. 
                   
                  GMPLS inter-domain routing must basically follow the GMPLS 
                  architecture [Arch], including the support of its exchange over out 
                  of band control channel. 
                   
                  5.2.2 Reachability information redistribution requirement 
                   
                  GMPLS inter-domain routing must provide redistribution mechanisms 
                  within the domain in a scalable manner. These information 
                  redistribution mechanisms must be designed to achieve such operation 
                  that a defect in a domain does not affect the scalability of intra-
                  domain routing in a different domain, although the GMPLS inter-domain 
                  routing must promptly advertise the failure within the domain, 
                  ensuring the GMPLS inter-domain connection establishment. 
                   
                  Mechanisms for redistributing GMPLS reachability information within 
                  the GMPLS domain can be I-BGP session, or re-injection to IGP. 
                  Especially, it is useful to adopt GMPLS end-to-end basis path 
                  calculation.  
                   
                    
                  T. Otani et al.  Informational - Expires April 2006               5 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
                  GMPLS inter-domain routing must have the functionality to consider 
                  any policies for controlling reachability information to be flooded, 
                  which will be defined between domains on a business or operational 
                  strategy basis. GMPLS inter-domain routing policy should be able to 
                  be changed and configured on a per domain basis. This policy control 
                  especially in terms of switching capability may be applicable to the 
                  extensions of hierarchical routing. Each domain should control the 
                  advertisement of the switching capability or re-advertisement of 
                  received switching capability. 
                   
                   
               6. Security consideration 
                   
                  GMPLS inter-domain routing should be implemented under a certain 
                  security consideration of the control plane as well as the data plane 
                  itself.  Indeed, this will not change the underlying security issues. 
                   
                   
               7. Acknowledgement 
                   
                  The authors would like to express the thanks to Naoaki Yamanaka for 
                  his support. 
                   
                   
               8. Intellectual property considerations 
                   
                  The IETF takes no position regarding the validity or scope of any 
                  Intellectual Property Rights 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; nor does it represent that it has 
                  made any independent effort to identify any such rights.  Information 
                  on the procedures with respect to rights in RFC documents can be 
                  found in BCP 78 and BCP 79. 
                   
                  Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at 
                  http://www.ietf.org/ipr. 
                   
                  The IETF invites any interested party to bring to its attention any 
                  copyrights, patents or patent applications, or other proprietary 
                  rights that may cover technology that may be required to implement 
                  this standard.  Please address the information to the IETF at ietf-
                  ipr@ietf.org. 
                   
                   
               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 April 2006               6 
                  draft-otani-ccamp-inter-domain-routing-req-00.txt      October 2005 
                   
                  [Inter-domain]  A. Farrel, et al, "A framework for inter-domain MPLS 
                                  traffic engineering", draft-ietf-ccamp-inter-fomain-
                                  framework-01.txt, February 2005. 
                  [Interas-te]   T. Otani, et al, “GMPLS Inter-domain Traffic 
                                  Engineering Requirements”, draft-otani-ccamp-interas-
                                  gmpls-te-03.txt, July 2005.  
                  [ASON routing] G.8080 
                  [OIF-ENNI]     DDPR 
                  [RFC 4105]     R. Zhan, et al, "Requirements for Inter-Area MPLS 
                                  Traffic Engineering”, RFC4105, June 2005. 
                  [Arch]         E. Mannie, et al, "Generalized Multi-Protocol Label 
                                  Switching Architecture", RFC3945, October, 2004. 
                  [ID-sig]       A. Ayyangar, “Inter domain GMPLS Traffic Engineering 
                                  - RSVP-TE extensions”, draft-ietf-ccamp-inter-domain-
                                  rsvp-te-02.txt, Oct. 2005. 
                   
                   
               Author's Addresses 
                   
                  Tomohiro Otani 
                  KDDI R&D Laboratories, Inc. 
                  2-1-15 Ohara Fujimino-shi     Phone:  +81-49-278-7357 
                  Saitama, 356-8502. Japan     Email:  otani@kddilabs.jp 
                   
                  Satoru Okamoto 
                  NTT Network Service System Laboratories 
                  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 April 30, 2006, unless it is updated. 
                   
                   
               Copyright statement 
                   
                  Copyright (C) The Internet Society (2005).  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 April 2006               7