Network work group                                           Mach Chen 
                                                          Renhai Zhang 
Internet Draft                             Huawei Technologies Co.,Ltd 
Expires: July 2007                                    January 30, 2007 
                                    
                                      
             OSPF Extensions in Support of Inter-AS (G)MPLS TE 
             draft-chen-ccamp-ospf-interas-te-extension-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 

   This Internet-Draft will expire on July 30, 2007. 

Abstract 

   This document describes extensions to the OSPF to support inter-AS 
   Traffic engineering (TE). It defines OSPF extensions for the flooding 
   of inter-AS links information which can be used to perform inter-AS 
   path computation. 

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. 

 
 
 
Mach & Renhai           Expires July 30, 2007                 [Page 1] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

Table of Contents 

    
   1. Introduction.................................................2 
   2. Problem statement............................................3 
   3. Extensions to OSPF...........................................4 
      3.1. Remote AS number sub-TLV................................4 
      3.2. Inter-AS Link type......................................5 
      3.3. Link ID.................................................5 
   4. Inter-AS links procedure.....................................5 
   5. Security Considerations......................................5 
   6. IANA Considerations..........................................6 
      6.1. Sub-TLVs types..........................................6 
      6.2. Link types..............................................6 
   7. References...................................................7 
      7.1. Normative References....................................7 
      7.2. Informative References..................................7 
   Author's Addresses..............................................8 
   Intellectual Property Statement.................................8 
   Disclaimer of Validity..........................................9 
   Copyright Statement.............................................9 
   Acknowledgment..................................................9 
    
1. Introduction 

   [OSPF-TE] defines extensions to the OSPF to support intra-area 
   Traffic Engineering (TE). The extensions provide a way of describing 
   the Traffic Engineering information and flooding this information 
   within an area. Type 10 opaque LSA is used to carry such TE 
   information. Two top-level TLVs are defined in [OSPF-TE]: Router 
   Address TLV and Link TLV, the Link TLV has several nested sub-TLVs 
   which describe the TE attribute for a TE enabled link. A node 
   advertises this TE information only if an IGP adjacency is 
   established over an intra-area link.  

   Inter-AS MPLS TE requirements are described in [INTERAS-TE-REQ]. As 
   described in [INTERAS-TE-REQ], a method SHOULD provide the ability to 
   compute a path spanning multiple ASes. So a path computation entity 
   (Head/Tail-end, ASBR or PCE) needs to know the TE information of not 
   only the links within an AS, but also the links that connect to other 
   ASes. 

   In this document, some extensions to [OSPF-TE] are defined in support 
   of carrying and flooding inter-AS links information for inter-AS 
   Traffic Engineering. A new sub-TLV is added to the Link TLV and a new 
   link type is introduced. The detailed definitions and procedures are 
   provided in the following sections. 
 
 
Mach & Renhai           Expires July 30, 2007                 [Page 2] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

2. Problem statement 

   As described in [INTERAS-TE-REQ], in the case of establishing an 
   inter-AS TE LSP which traverses multiple ASes, the signaling protocol 
   may contain the following elements in the Explicit Route Object(ERO): 

     -a set of AS numbers as loose hop and/or 

     -a set of LSRs including ASBRs 

   In per domain method, when each entry LSR within an AS receives a 
   PATH message from the upstream AS with the ERO containing a sequence 
   of ASes, it SHOULD be able to find which LSRs within the local AS are 
   connected to the downstream AS, therefore compute a TE LSP segment to 
   that LSR, and pass this PATH message to it. See the below figure for 
   example: 

               R1-----R3-----R5-----R6------R9-----R11 
               |      |     /  \    |       | 
               R2-----R4---     ----R8------R10----R12 
               <=AS 1=>     <==AS 2= >     <=AS 3=> 
                    Figure 1: Inter-AS Reference Model 

   If an inter-AS TE LSP is to be established from R1 within AS 1 to R12 
   within AS 3, the AS sequence will be traversed as: AS1, AS2 and AS3. 
   The PATH message is constructed and sent from R1. When R5 within AS 2 
   receives the PATH message, R5 SHOULD firstly be able to determine 
   that there are two ASBRs and two inter-AS links connected to AS 3, 
   then R5 SHOULD be able to choose a feasible route to the entry LSR(R9 
   or R10) within AS 3. To make these abilities possible for R5, besides 
   the usual TE database information including the inter-AS TE links 
   (R6-R9, R8-R10), R5 SHOULD also maintain the following information 
   for each inter-AS TE link:  

      -an indication that this is an inter-AS link 

      -the neighboring AS 
       -the neighboring ASBR in the neighboring AS 

   This information is needed throughout the local AS if path 
   computation function is fully distributed among LSRs within the local 
   AS.  

   Another scenario using PCE technique also has the above problem. 
   [BRPC] defines a PCE-based TE LSP computation method to compute 
   optimal inter-domain constrained (G)MPLS TE LSPs. In this path 
   computation method, a set of specific traversed domains are assumed 
 
 
Mach & Renhai           Expires July 30, 2007                 [Page 3] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

   to be selected before the computation starts. Each downstream PCE in 
   domain(i) SHOULD return a VSPT to the upstream PCE in domain(i-1), 
   where VSPT is a MP2P tree from Boundary Nodes located in domain(i) to 
   the destination that satisfies the set of required constraints for 
   the TE LSP (bandwidth, affinities, ...). So a PCE needs to locate 
   Boundary Nodes that provide connectivity from a specified AS. For 
   inter-AS TE stated in this document, the PCE MUST have the knowledge 
   of inter-AS links information to locate the ASBRs connected with 
   remote ASes. 

   An extension to IGP is introduced in this draft to flood inter-AS 
   links information among LSRs within the local AS. BGP extension to 
   flood this information for PCE is out of scope of this document. 

3. Extensions to OSPF 

   In this document, we use the Type 11 Opaque LSAs, which have an AS 
   flooding scope. That is, inter-AS TE links SHOULD be flooded within a 
   whole AS, each router in the AS can receive those inter-AS TE links 
   and can use such information for inter-AS path computation. 

3.1. Remote AS number sub-TLV 

   As described in [OSPF-TE], the Link TLV describes a single link and 
   it consists of a set of sub-TLVs. In this document, a new sub-TLV, 
   Remote AS number sub-TLV is added to the Link TLV when advertising 
   inter-AS links. The Remote AS number sub-TLV specifies the AS number 
   of the neighboring AS corresponding to this link. 

   The Remote AS number sub-TLV is TLV type 18 (which needs to be 
   confirmed by IANA), and is four octets in length. The format is as 
   follows: 

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |              Type             |             Length            |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
   |                       Remote AS Number                        |            
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    

   The Remote AS number field has 4 octets, when two octets are used for 
   AS number in current implementation, the left two octets MUST be set 
   to zero. 

    

 
 
Mach & Renhai           Expires July 30, 2007                 [Page 4] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

3.2. Inter-AS Link type 

   To identify a link to be an inter-AS link, a new Link type, inter-AS 
   link is specified, the value of inter-AS link type is 3 (which needs 
   to be confirmed by IANA). 

3.3. Link ID 

   For an inter-AS link, the Link ID is the remote ASBR Router ID 
   corresponding to this inter-AS link. 

4. Inter-AS links procedure 

   Although there is no OSPF adjacency running over an inter-AS link, 
   the ASBR SHOULD advertise this link to all nodes within its AS when 
   TE is enabled on the link and the link is up. When either the link is 
   down or TE is disabled on the link, the ASBR SHOULD withdraw the 
   advertisement. 

   As a result of such advertisement, all nodes in that AS will get 
   those inter-AS links information. An AS Boundary Connection table 
   COULD be established to efficiently maintain those information. Each 
   table entry SHOULD at least consist of Router ID of Local ASBR, 
   Router ID of remote ASBR, Remote AS number. Take Figure 1 for example 
   again, AS Boundary Connect table of R5 should include such 
   information as below: 

              Remote AS number Local Router ID Remote Router ID  
              -------------------------------------------------- 
                     AS1           R5            R3  
                     AS1           R5            R4  
                     AS3           R6            R9 
                     AS3           R8            R10 
    
              Table 1: The AS Boundary Connect table for R5 
    

   By looking up this table, a path computation entity can identify an 
   ASBR to reach the next AS. PCE can also identify all ASBRs connected 
   to a specified AS. 

5. Security Considerations 

   This extension to OSPF does not change the underlying security issues. 



 
 
Mach & Renhai           Expires July 30, 2007                 [Page 5] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

6. IANA Considerations 

6.1. Sub-TLVs types 

   Value   Meaning 

     18   Remote AS number sub-TLV. 

6.2. Link types 

   Value   Meaning 

     3   inter-AS link type. 

































 
 
Mach & Renhai           Expires July 30, 2007                 [Page 6] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

7. References 

7.1. Normative References 

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP              
             Tunnels", RFC 3209, December 2001. 

   [RFC2370]  R. Coltun, "The OSPF Opaque LSA Option", RFC2370, July 
             1998. 

   [OSPF]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April                   
             1998. 

   [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic    
             Engineering Requirements", RFC4216, November 2005. 

   [OSPF-TE] Katz, D., Kompella, K., and Yeung, D., "Traffic                   
             Engineering (TE) Extensions to OSPF Version 2", RFC                
             3630, September 2003. 

   [CCAMP-INTER-DOMAIN-TE] Ayyangar, A. and J. Vasseur, "Inter domain 
             GMPLS Traffic Engineering - RSVP-TE extensions",draft-ietf-
             ccamp-inter-domain-rsvp-te-04 (work in progress), January 
             2007. 

7.2. Informative References 

   [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic    
             Engineering Requirements", RFC4216, November 2005. 

   [PER-DOMAIN] Ayyangar, A., Vasseur, J., and Zhang, R., "A Per-domain 
             path computation method for establishing Inter-domain", 
             draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in 
             progress), August, 2006. 

   [BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward 
             Recursive PCE-based Computation (BRPC) procedure to compute 
             shortest inter-domain Traffic Engineering Label Switched 
             Paths ", draft-ietf-pce-brpc-03.txt, Work in Progress, 
             January 2007. 



 
 
Mach & Renhai           Expires July 30, 2007                 [Page 7] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

Author's Addresses 

   Mach Chen 
   Huawei Technologies Co.,Ltd 
   KuiKe Building, No.9 Xinxi Rd., 
   Hai-Dian District  
   Beijing, 100085 
   P.R. China 
      
   Email: mach@huawei.com 
 

   Renhai Zhang 
   Huawei Technologies Co.,Ltd 
   KuiKe Building, No.9 Xinxi Rd., 
   Hai-Dian District  
   Beijing, 100085 
   P.R. China 
      
   Email: zhangrenhai@huawei.com 
 

Intellectual Property Statement 

   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. 


 
 
Mach & Renhai           Expires July 30, 2007                 [Page 8] 

Internet-Draft  Inter-AS Links connection information      January 2007 
    

Disclaimer of Validity 

   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, THE IETF TRUST 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. 

Copyright Statement 

   Copyright (C) The IETF Trust (2007). 

   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. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

 






















 
 
Mach & Renhai           Expires July 30, 2007                 [Page 9]