doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5392.txt b/doc/rfc/rfc5392.txt
new file mode 100644
index 0000000..6b7bac0
--- /dev/null
+++ b/doc/rfc/rfc5392.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                           M. Chen
+Request for Comments: 5392                                     R. Zhang
+Category: Standards Track                 Huawei Technologies Co., Ltd.
+                                                                X. Duan
+                                                           China Mobile
+                                                           January 2009
+
+
+      OSPF Extensions in Support of Inter-Autonomous System (AS)
+                  MPLS and GMPLS Traffic Engineering
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes extensions to the OSPF version 2 and 3
+   protocols to support Multiprotocol Label Switching (MPLS) and
+   Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
+   Autonomous Systems (ASes).  OSPF-TE v2 and v3 extensions are defined
+   for the flooding of TE information about inter-AS links that can be
+   used to perform inter-AS TE path computation.
+
+   No support for flooding information from within one AS to another AS
+   is proposed or defined in this document.
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 1]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. Problem Statement ...............................................3
+      2.1. A Note on Non-Objectives ...................................4
+      2.2. Per-Domain Path Determination ..............................4
+      2.3. Backward Recursive Path Computation ........................6
+   3. Extensions to OSPF ..............................................7
+      3.1. LSA Definitions ............................................8
+           3.1.1. Inter-AS-TE-v2 LSA ..................................8
+           3.1.2. Inter-AS-TE-v3 LSA ..................................8
+      3.2. LSA Payload ................................................9
+           3.2.1. Link TLV ............................................9
+      3.3. Sub-TLV Details ...........................................10
+           3.3.1. Remote AS Number Sub-TLV ...........................10
+           3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................11
+           3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11
+   4. Procedure for Inter-AS TE Links ................................12
+      4.1. Origin of Proxied TE Information ..........................13
+   5. Security Considerations ........................................14
+   6. IANA Considerations ............................................14
+      6.1. Inter-AS TE OSPF LSA ......................................14
+           6.1.1. Inter-AS-TE-v2 LSA .................................14
+           6.1.2. Inter-AS-TE-v3 LSA .................................14
+      6.2. OSPF LSA Sub-TLVs Type ....................................15
+   7. Acknowledgments ................................................15
+   8. References .....................................................15
+      8.1. Normative References ......................................15
+      8.2. Informative References ....................................16
+
+1.  Introduction
+
+   [OSPF-TE] defines extensions to the OSPF protocol [OSPF] to support
+   intra-area Traffic Engineering (TE).  The extensions provide a way of
+   encoding the TE information for TE-enabled links within the network
+   (TE links) and flooding this information within an area.  Type 10
+   Opaque Link State Advertisements (LSAs) [RFC5250] are used to carry
+   such TE information.  Two top-level Type Length Values (TLVs) are
+   defined in [OSPF-TE]: Router Address TLV and Link TLV.  The Link TLV
+   has several nested sub-TLVs that describe the TE attributes for a TE
+   link.
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 2]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   [OSPF-V3-TE] defines similar extensions to OSPFv3 [OSPFV3].  It
+   defines a new LSA, which is referred to as the Intra-Area-TE LSA, to
+   advertise TE information.  [OSPF-V3-TE] uses "Traffic Engineering
+   Extensions to OSPF" [OSPF-TE] as a base for TLV definitions and
+   defines some new TLVs and sub-TLVs to extend TE capabilities to IPv6
+   networks.
+
+   Requirements for establishing Multiprotocol Label Switching Traffic
+   Engineering (MPLS-TE) Label Switched Paths (LSPs) that cross multiple
+   Autonomous Systems (ASes) are described in [INTER-AS-TE-REQ].  As
+   described in [INTER-AS-TE-REQ], a method SHOULD provide the ability
+   to compute a path spanning multiple ASes.  So a path computation
+   entity that may be the head-end Label Switching Router (LSR), an AS
+   Border Router (ASBR), or a Path Computation Element [PCE] needs to
+   know the TE information not only of the links within an AS, but also
+   of the links that connect to other ASes.
+
+   In this document, two new separate LSAs are defined to advertise
+   inter-AS TE information for OSPFv2 and OSPFv3, respectively, and
+   three new sub-TLVs are added to the existing Link TLV to extend TE
+   capabilities for inter-AS Traffic Engineering.  The detailed
+   definitions and procedures are discussed in the following sections.
+
+   This document does not propose or define any mechanisms to advertise
+   any other extra-AS TE information within OSPF.  See Section 2.1 for a
+   full list of non-objectives for this work.
+
+1.1.  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].
+
+2.  Problem Statement
+
+   As described in [INTER-AS-TE-REQ], in the case of establishing an
+   inter-AS TE LSP traversing multiple ASes, the Path message [RFC3209]
+   may include the following elements in the Explicit Route Object (ERO)
+   in order to describe the path of the LSP:
+
+      - a set of AS numbers as loose hops; and/or
+
+      - a set of LSRs including ASBRs as loose hops.
+
+   Two methods for determining inter-AS paths are currently being
+   discussed.  The per-domain method [PD-PATH] determines the path one
+   domain at a time.  The backward recursive method [BRPC] uses
+   cooperation between PCEs to determine an optimum inter-domain path.
+
+
+
+Chen, et al.                Standards Track                     [Page 3]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   The sections that follow examine how inter-AS TE link information
+   could be useful in both cases.
+
+2.1.  A Note on Non-Objectives
+
+   It is important to note that this document does not make any change
+   to the confidentiality and scaling assumptions surrounding the use of
+   ASes in the Internet.  In particular, this document is conformant to
+   the requirements set out in [INTER-AS-TE-REQ].
+
+   The following features are explicitly excluded:
+
+      o There is no attempt to distribute TE information from within one
+        AS to another AS.
+
+      o There is no mechanism proposed to distribute any form of TE
+        reachability information for destinations outside the AS.
+
+      o There is no proposed change to the PCE architecture or usage.
+
+      o TE aggregation is not supported or recommended.
+
+      o There is no exchange of private information between ASes.
+
+      o No OSPF adjacencies are formed on the inter-AS link.
+
+   Note also that the extensions proposed in this document are used only
+   to advertise information about inter-AS TE links.  As such these
+   extensions address an entirely different problem from L1VPN Auto-
+   Discovery [L1VPN-OSPF-AD], which defines how TE information about
+   links between Customer Edge (CE) equipment and Provider Edge (PE)
+   equipment can be advertised in OSPF-TE alongside the auto-discovery
+   information for the CE-PE links.  There is no overlap between this
+   document and [L1VPN-OSPF-AD].
+
+2.2.  Per-Domain Path Determination
+
+   In the per-domain method of determining an inter-AS path for an
+   MPLS-TE LSP, when an LSR that is an entry point to an AS receives a
+   Path message from an upstream AS with an ERO containing a next hop
+   that is an AS number, it needs to find which LSRs (ASBRs) within the
+   local AS are connected to the downstream AS so that it can compute a
+   TE LSP segment across the local AS to one of those LSRs and forward
+   the Path message to it and hence into the next AS.  See Figure 1 for
+   an example:
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 4]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+            R1------R3----R5-----R7------R9-----R11
+                    |     | \    |      / |
+                    |     |  \   |  ----  |
+                    |     |   \  | /      |
+            R2------R4----R6   --R8------R10----R12
+                       :              :
+            <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+              Figure 1: Inter-AS Reference Model
+
+   The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1
+   through R12).  R3 and R4 are ASBRs in AS1.  R5, R6, R7, and R8 are
+   ASBRs in AS2.  R9 and R10 are ASBRs in AS3.
+
+   If an inter-AS TE LSP is planned to be established from R1 to R12,
+   the AS sequence will be: AS1, AS2, AS3.
+
+   Suppose that the Path message enters AS2 from R3.  The next hop in
+   the ERO shows AS3, and R5 must determine a path segment across AS2 to
+   reach AS3.  It has a choice of three exit points from AS2 (R6, R7,
+   and R8) and it needs to know which of these provide TE connectivity
+   to AS3, and whether the TE connectivity (for example, available
+   bandwidth) is adequate for the requested LSP.
+
+   Alternatively, if the next hop in the ERO is the entry ASBR for AS3
+   (say R9), R5 needs to know which of its exit ASBRs has a TE link that
+   connects to R9.  Since there may be multiple ASBRs that are connected
+   to R9 (both R7 and R8 in this example), R5 also needs to know the TE
+   properties of the inter-AS TE links so that it can select the correct
+   exit ASBR.
+
+   Once the path message reaches the exit ASBR, any choice of inter-AS
+   TE link can be made by the ASBR if not already made by the entry ASBR
+   that computed the segment.
+
+   More details can be found in Section 4 of [PD-PATH], which clearly
+   points out why the advertising of inter-AS links is desired.
+
+   To enable R5 to make the correct choice of exit ASBR, the following
+   information is needed:
+
+      o List of all inter-AS TE links for the local AS.
+
+      o TE properties of each inter-AS TE link.
+
+      o AS number of the neighboring AS to which each inter-AS TE link
+        is connected.
+
+
+
+
+Chen, et al.                Standards Track                     [Page 5]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+      o Identity (TE Router ID) of the neighboring ASBR to which each
+        inter-AS TE link is connected.
+
+   In GMPLS networks, further information may also be required to select
+   the correct TE links as defined in [GMPLS-TE].
+
+   The example above shows how this information is needed at the entry
+   point ASBRs for each AS (or the PCEs that provide computation
+   services for the ASBRs), but this information is also needed
+   throughout the local AS if path computation function is fully
+   distributed among LSRs in the local AS, for example, to support LSPs
+   that have start points (ingress nodes) within the AS.
+
+2.3.  Backward Recursive Path Computation
+
+   Another scenario using PCE techniques has the same problem.  [BRPC]
+   defines a PCE-based TE LSP computation method (called Backward
+   Recursive Path Computation) to compute optimal inter-domain
+   constrained MPLS-TE or GMPLS LSPs.  In this path computation method,
+   a specific set of traversed domains (ASes) are assumed to be selected
+   before computation starts.  Each downstream PCE in domain(i) returns
+   to its upstream neighbor PCE in domain(i-1) a multipoint-to-point
+   tree of potential paths.  Each tree consists of the set of paths from
+   all Boundary Nodes located in domain(i) to the destination where each
+   path satisfies the set of required constraints for the TE LSP
+   (bandwidth, affinities, etc.).
+
+   So a PCE needs to select Boundary Nodes (that is, ASBRs) that provide
+   connectivity from the upstream AS.  In order that the tree of paths
+   provided by one PCE to its neighbor can be correlated, the identities
+   of the ASBRs for each path need to be referenced, so the PCE must
+   know the identities of the ASBRs in the remote AS reached by any
+   inter-AS TE link, and, in order that it provides only suitable paths
+   in the tree, the PCE must know the TE properties of the inter-AS TE
+   links.  See the following figure as an example:
+
+                   PCE1<------>PCE2<-------->PCE3
+                   /       :             :
+                  /        :             :
+                R1------R3----R5-----R7------R9-----R11
+                        |     | \    |      / |
+                        |     |  \   |  ----  |
+                        |     |   \  | /      |
+                R2------R4----R6   --R8------R10----R12
+                           :              :
+                <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+              Figure 2: BRPC for Inter-AS Reference Model
+
+
+
+Chen, et al.                Standards Track                     [Page 6]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1,
+   PCE2, and PCE3), and twelve LSRs (R1 through R12).  R3 and R4 are
+   ASBRs in AS1.  R5, R6, R7, and R8 are ASBRs in AS2.  R9 and R10 are
+   ASBRs in AS3.  PCE1, PCE2, and PCE3 cooperate to perform inter-AS
+   path computation and are responsible for path segment computation
+   within their own domain(s).
+
+   If an inter-AS TE LSP is planned to be established from R1 to R12,
+   the traversed domains are assumed to be selected: AS1->AS2->AS3, and
+   the PCE chain is: PCE1->PCE2->PCE3.  First, the path computation
+   request originated from the Path Computation Client (R1) is relayed
+   by PCE1 and PCE2 along the PCE chain to PCE3, then PCE3 begins to
+   compute the path segments from the entry boundary nodes that provide
+   connection from AS2 to the destination (R12).  But, to provide
+   suitable path segments, PCE3 must determine which entry boundary
+   nodes provide connectivity to its upstream neighbor AS (identified by
+   its AS number), and must know the TE properties of the inter-AS TE
+   links.  In the same way, PCE2 also needs to determine the entry
+   boundary nodes according to its upstream neighbor AS and the inter-AS
+   TE link capabilities.
+
+   Thus, to support Backward Recursive Path Computation the same
+   information listed in Section 2.2 is required.  The AS number of the
+   neighboring AS to which each inter-AS TE link is connected is
+   particularly important.
+
+3.  Extensions to OSPF
+
+   Note that this document does not define mechanisms for distribution
+   of TE information from one AS to another, does not distribute any
+   form of TE reachability information for destinations outside the AS,
+   does not change the PCE architecture or usage, does not suggest or
+   recommend any form of TE aggregation, and does not feed private
+   information between ASes.  See Section 2.1.
+
+   The extensions defined in this document allow an inter-AS TE link
+   advertisement to be easily identified as such by the use of two new
+   types of LSA, which are referred to as Inter-AS-TE-v2 LSA and
+   Inter-AS-TE-v3 LSA.  Three new sub-TLVs are added to the Link TLV to
+   carry the information about the neighboring AS and the remote ASBR.
+
+   While some of the TE information of an inter-AS TE link may be
+   available within the AS from other protocols, in order to avoid any
+   dependency on where such protocols are processed, this mechanism
+   carries all the information needed for the required TE operations.
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 7]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+3.1.  LSA Definitions
+
+3.1.1.  Inter-AS-TE-v2 LSA
+
+   For the advertisement of OSPFv2 inter-AS TE links, a new Opaque LSA,
+   the Inter-AS-TE-v2 LSA, is defined in this document.  The
+   Inter-AS-TE-v2 LSA has the same format as "Traffic Engineering LSA",
+   which is defined in [OSPF-TE].
+
+   The inter-AS TE link advertisement SHOULD be carried in a Type 10
+   Opaque LSA [RFC5250] if the flooding scope is to be limited to within
+   the single IGP area to which the ASBR belongs, or MAY be carried in a
+   Type 11 Opaque LSA [RFC5250] if the information is intended to reach
+   all routers (including area border routers, ASBRs, and PCEs) in the
+   AS.  The choice between the use of a Type 10 (area-scoped) or Type 11
+   (AS-scoped) Opaque LSA is an AS-wide policy choice, and configuration
+   control of it SHOULD be provided in ASBR implementations that support
+   the advertisement of inter-AS TE links.
+
+   The Link State ID of an Opaque LSA as defined in [RFC5250] is divided
+   into two parts.  One of them is the Opaque type (8-bit), the other is
+   the Opaque ID (24-bit).  The value for the Opaque type of
+   Inter-AS-TE-v2 LSA is 6 and has been assigned by IANA (see Section
+   6.1).  The Opaque ID of the Inter-AS-TE-v2 LSA is an arbitrary value
+   used to uniquely identify Traffic Engineering LSAs.  The Link State
+   ID has no topological significance.
+
+   The TLVs within the body of an Inter-AS-TE-v2 LSA have the same
+   format as used in OSPF-TE.  The payload of the TLVs consists of one
+   or more nested Type/Length/Value triplets.  New sub-TLVs specifically
+   for inter-AS TE Link advertisement are described in Section 3.2.
+
+3.1.2.  Inter-AS-TE-v3 LSA
+
+   In this document, a new LS type is defined for OSPFv3 inter-AS TE
+   link advertisement.  The new LS type function code is 13 (see Section
+   6.1).
+
+   The format of an Inter-AS-TE-v3 LSA follows the standard definition
+   of an OSPFv3 LSA as defined in [OSPFV3].
+
+   The high-order three bits of the LS type field of the OSPFv3 LSA
+   header encode generic properties of the LSA and are termed the U-bit,
+   S2-bit, and S1-bit [OSPFV3].  The remainder of the LS type carries
+   the LSA function code.
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 8]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   For the Inter-AS-TE-v3-LSA, the bits are set as follows:
+
+   The U-bit is always set to 1 to indicate that an OSPFv3 router MUST
+   flood the LSA at its defined flooding scope even if it does not
+   recognize the LS type.
+
+   The S2 and S1 bits indicate the flooding scope of an LSA.  For the
+   Inter-AS-TE-v3-LSA, the S2 and S1 bits SHOULD be set to 01 to
+   indicate that the flooding scope is to be limited to within the
+   single IGP area to which the ASBR belongs, but MAY be set to 10 if
+   the information should reach all routers (including area border
+   routers, ASBRs, and PCEs) in the AS.  The choice between the use of
+   01 or 10 is a network-wide policy choice, and configuration control
+   SHOULD be provided in ASBR implementations that support the
+   advertisement of inter-AS TE links.
+
+   The Link State ID of the Inter-AS-TE-v3 LSA is an arbitrary value
+   used to uniquely identify Traffic Engineering LSAs.  The LSA ID has
+   no topological significance.
+
+   The TLVs within the body of an Inter-AS-TE-v3 LSA have the same
+   format and semantics as those defined in [OSPF-V3-TE].  New sub-TLVs
+   specifically for inter-AS TE Link advertisement are described in
+   Section 3.2.
+
+3.2.  LSA Payload
+
+   Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA contain one top
+   level TLV:
+
+      2 - Link TLV
+
+   For the Inter-AS-TE-v2 LSA, this TLV is defined in [OSPF-TE], and for
+   the Inter-AS-TE-v3 LSA, this TLV is defined in [OSPF-V3-TE].  The
+   sub-TLVs carried in this TLV are described in the following sections.
+
+3.2.1.  Link TLV
+
+   The Link TLV describes a single link and consists a set of sub-TLVs.
+   The sub-TLVs for inclusion in the Link TLV of the Inter-AS-TE-v2 LSA
+   and Inter-AS-TE-v3 LSA are defined, respectively, in [OSPF-TE] and
+   [OSPF-V3-TE], and the list of sub-TLVs may be extended by other
+   documents.  However, this document defines the following exceptions.
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 9]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   The Link ID sub-TLV [OSPF-TE] MUST NOT be used in the Link TLV of an
+   Inter-AS-TE-v2 LSA, and the Neighbor ID sub-TLV [OSPF-V3-TE] MUST NOT
+   be used in the Link TLV of an Inter-AS-TE-v3 LSA.  Given that OSPF is
+   an IGP and should only be utilized between routers in the same
+   routing domain, the OSPF specific Link ID and Neighbor ID sub-TLVs
+   are not applicable to inter-AS links.
+
+   Instead, the remote ASBR is identified by the inclusion of the
+   following new sub-TLVs defined in this document and described in the
+   subsequent sections.
+
+      21 - Remote AS Number sub-TLV
+
+      22 - IPv4 Remote ASBR ID sub-TLV
+
+      23 - IPv6 Remote ASBR ID sub-TLV
+
+   The Remote-AS-Number sub-TLV MUST be included in the Link TLV of both
+   the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA.  At least one of the
+   IPv4-Remote-ASBR-ID sub-TLV and the IPv6-Remote-ASBR-ID sub-TLV
+   SHOULD be included in the Link TLV of the Inter-AS-TE-v2 LSA and
+   Inter-AS-TE-v3 LSA.  Note that it is possible to include the
+   IPv6-Remote-ASBR-ID sub-TLV in the Link TLV of the Inter-AS-TE-v2
+   LSA, and to include the IPv4-Remote-ASBR-ID sub-TLV in the Link TLV
+   of the Inter-AS-TE-v3 LSA because the sub-TLVs refer to ASBRs that
+   are in a different addressing scope (that is, a different AS) from
+   that where the OSPF LSA is used.
+
+3.3.  Sub-TLV Details
+
+3.3.1.  Remote AS Number Sub-TLV
+
+   A new sub-TLV, the Remote AS Number sub-TLV is defined for inclusion
+   in the Link TLV when advertising inter-AS links.  The Remote AS
+   Number sub-TLV specifies the AS number of the neighboring AS to which
+   the advertised link connects.  The Remote AS Number sub-TLV is
+   REQUIRED in a Link TLV that advertises an inter-AS TE link.
+
+   The Remote AS Number sub-TLV is TLV type 21 (see Section 6.2), and is
+   four octets in length.  The format is as follows:
+
+    0                   1                   2                   3
+    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                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Chen, et al.                Standards Track                    [Page 10]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+
+   The Remote AS Number field has 4 octets.  When only two octets are
+   used for the AS number, as in current deployments, the left (high-
+   order) two octets MUST be set to zero.
+
+3.3.2.  IPv4 Remote ASBR ID Sub-TLV
+
+   A new sub-TLV, which is referred to as the IPv4 Remote ASBR ID sub-
+   TLV, can be included in the Link TLV when advertising inter-AS links.
+   The IPv4 Remote ASBR ID sub-TLV specifies the IPv4 identifier of the
+   remote ASBR to which the advertised inter-AS link connects.  This
+   could be any stable and routable IPv4 address of the remote ASBR.
+   Use of the TE Router Address TE Router ID as specified in the Router
+   Address TLV [OSPF-TE] is RECOMMENDED.
+
+   The IPv4 Remote ASBR ID sub-TLV is TLV type 22 (see Section 6.2), and
+   is four octets in length.  Its format is as follows:
+
+    0                   1                   2                   3
+    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 ASBR ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   In OSPFv2 advertisements, the IPv4 Remote ASBR ID sub-TLV MUST be
+   included if the neighboring ASBR has an IPv4 address.  If the
+   neighboring ASBR does not have an IPv4 address (not even an IPv4 TE
+   Router ID), the IPv6 Remote ASBR ID sub-TLV MUST be included instead.
+   An IPv4 Remote ASBR ID sub-TLV and IPv6 Remote ASBR ID sub-TLV MAY
+   both be present in a Link TLV in OSPFv2 or OSPFv3.
+
+3.3.3.  IPv6 Remote ASBR ID Sub-TLV
+
+   A new sub-TLV, which is referred to as the IPv6 Remote ASBR ID sub-
+   TLV, can be included in the Link TLV when advertising inter-AS links.
+   The IPv6 Remote ASBR ID sub-TLV specifies the identifier of the
+   remote ASBR to which the advertised inter-AS link connects.  This
+   could be any stable, routable, and global IPv6 address of the remote
+   ASBR.  Use of the TE Router IPv6 Address IPv6 TE Router ID as
+   specified in the IPv6 Router Address, which is specified in the IPv6
+   Router Address TLV [OSPF-V3-TE], is RECOMMENDED.
+
+   The IPv6 Remote ASBR ID sub-TLV is TLV type 24 (see Section 6.2), and
+   is sixteen octets in length.  Its format is as follows:
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 11]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+    0                   1                   2                   3
+    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 ASBR ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   In OSPFv3 advertisements, the IPv6 Remote ASBR ID sub-TLV MUST be
+   included if the neighboring ASBR has an IPv6 address.  If the
+   neighboring ASBR does not have an IPv6 address, the IPv4 Remote ASBR
+   ID sub-TLV MUST be included instead.  An IPv4 Remote ASBR ID sub-TLV
+   and IPv6 Remote ASBR ID sub-TLV MAY both be present in a Link TLV in
+   OSPFv2 or OSPFv3.
+
+4.  Procedure for Inter-AS TE Links
+
+   When TE is enabled on an inter-AS link and the link is up, the ASBR
+   SHOULD advertise this link using the normal procedures for OSPF-TE
+   [OSPF-TE].  When either the link is down or TE is disabled on the
+   link, the ASBR SHOULD withdraw the advertisement.  When there are
+   changes to the TE parameters for the link (for example, when the
+   available bandwidth changes), the ASBR SHOULD re-advertise the link,
+   but the ASBR MUST take precautions against excessive re-
+   advertisements as described in [OSPF-TE].
+
+   Hellos MUST NOT be exchanged over the inter-AS link, and
+   consequently, an OSPF adjacency MUST NOT be formed.
+
+   The information advertised comes from the ASBR's knowledge of the TE
+   capabilities of the link, the ASBR's knowledge of the current status
+   and usage of the link, and configuration at the ASBR of the remote AS
+   number and remote ASBR TE Router ID.
+
+   Legacy routers receiving an advertisement for an inter-AS TE link are
+   able to ignore it because the Link Type carries an unknown value.
+   They will continue to flood the LSA, but will not attempt to use the
+   information received as if the link were an intra-AS TE link.
+
+   In the current operation of TE OSPF, the LSRs at each end of a TE
+   link emit LSAs describing the link.  The databases in the LSRs then
+   have two entries (one locally generated, the other from the peer)
+
+
+
+Chen, et al.                Standards Track                    [Page 12]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   that describe the different 'directions' of the link.  This enables
+   Constrained Shortest Path First (CSPF) to do a two-way check on the
+   link when performing path computation and eliminate it from
+   consideration unless both directions of the link satisfy the required
+   constraints.
+
+   In the case we are considering here (i.e., of a TE link to another
+   AS), there is, by definition, no IGP peering and hence no
+   bidirectional TE link information.  In order for the CSPF route
+   computation entity to include the link as a candidate path, we have
+   to find a way to get LSAs describing its (bidirectional) TE
+   properties into the TE database.
+
+   This is achieved by the ASBR advertising, internally to its AS,
+   information about both directions of the TE link to the next AS.  The
+   ASBR will normally generate an LSA describing its own side of a link;
+   here we have it 'proxy' for the ASBR at the edge of the other AS and
+   generate an additional LSA that describes that device's 'view' of the
+   link.
+
+   Only some essential TE information for the link needs to be
+   advertised; i.e., the Link Type, the Remote AS number, and the Remote
+   ASBR ID.  Routers or PCEs that are capable of processing
+   advertisements of inter-AS TE links SHOULD NOT use such links to
+   compute paths that exit an AS to a remote ASBR and then immediately
+   re-enter the AS through another TE link.  Such paths would constitute
+   extremely rare occurrences and SHOULD NOT be allowed except as the
+   result of specific policy configurations at the router or PCE
+   computing the path.
+
+4.1.  Origin of Proxied TE Information
+
+   Section 4 describes how an ASBR advertises TE link information as a
+   proxy for its neighbor ASBR, but does not describe where this
+   information comes from.
+
+   Although the source of this information is outside the scope of this
+   document, it is possible that it will be a configuration requirement
+   at the ASBR, as are other, local, properties of the TE link.
+   Further, where BGP is used to exchange IP routing information between
+   the ASBRs, a certain amount of additional local configuration about
+   the link and the remote ASBR is likely to be available.
+
+   We note further that it is possible, and may be operationally
+   advantageous, to obtain some of the required configuration
+   information from BGP.  Whether and how to utilize these possibilities
+   is an implementation matter.
+
+
+
+
+Chen, et al.                Standards Track                    [Page 13]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+5.  Security Considerations
+
+   The protocol extensions defined in this document are relatively minor
+   and can be secured within the AS in which they are used by the
+   existing OSPF security mechanisms.
+
+   There is no exchange of information between ASes, and no change to
+   the OSPF security relationship between the ASes.  In particular,
+   since no OSPF adjacency is formed on the inter-AS links, there is no
+   requirement for OSPF security between the ASes.
+
+   Some of the information included in these new advertisements (e.g.,
+   the remote AS number and the remote ASBR ID) is obtained manually
+   from a neighboring administration as part of commercial relationship.
+   The source and content of this information should be carefully
+   checked before it is entered as configuration information at the ASBR
+   responsible for advertising the inter-AS TE links.
+
+   It is worth noting that, in the scenario we are considering, a Border
+   Gateway Protocol (BGP) peering may exist between the two ASBRs, and
+   this could be used to detect inconsistencies in configuration (e.g.,
+   the administration that originally supplied the information may be
+   lying, or some manual misconfigurations or mistakes are made by the
+   operators).  For example, if a different remote AS number is received
+   in a BGP OPEN [BGP] from that locally configured into OSPF-TE, as we
+   describe here, then local policy SHOULD be applied to determine
+   whether to alert the operator to a potential misconfiguration or to
+   suppress the OSPF advertisement of the inter-AS TE link.  Note,
+   further, that if BGP is used to exchange TE information as described
+   in Section 4.1, the inter-AS BGP session SHOULD be secured using
+   mechanisms as described in [BGP] to provide authentication and
+   integrity checks.
+
+6.  IANA Considerations
+
+   IANA has made the following allocations from registries under its
+   control.
+
+6.1.  Inter-AS TE OSPF LSA
+
+6.1.1.  Inter-AS-TE-v2 LSA
+
+   IANA has assigned a new Opaque LSA type (6) to Inter-AS-TE-v2 LSA.
+
+6.1.2.  Inter-AS-TE-v3 LSA
+
+   IANA has assigned a new OSPFv3 LSA type function code (13) to Inter-
+   AS-TE-v3 LSA.
+
+
+
+Chen, et al.                Standards Track                    [Page 14]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+6.2.  OSPF LSA Sub-TLVs Type
+
+   IANA maintains the "Open Shortest Path First (OSPF) Traffic
+   Engineering TLVs" registry with sub-registry "Types for sub-TLVs in a
+   TE Link TLV".  IANA has assigned three new sub-TLVs as follows (see
+   Section 3.3 for details):
+
+   Value     Meaning
+
+   21        Remote AS Number sub-TLV
+
+   22        IPv4 Remote ASBR ID sub-TLV
+
+   24        IPv6 Remote ASBR ID sub-TLV
+
+7.  Acknowledgments
+
+   The authors would like to thank Adrian Farrel, Acee Lindem, JP
+   Vasseur, Dean Cheng, and Jean-Louis Le Roux for their review and
+   comments to this document.
+
+8.  References
+
+8.1.  Normative References
+
+   [GMPLS-TE]        Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
+                     Extensions in Support of Generalized Multi-Protocol
+                     Label Switching (GMPLS)", RFC 4203, October 2005.
+
+   [OSPF]            Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                     1998.
+
+   [OSPF-TE]         Katz, D., Kompella, K., and D. Yeung, "Traffic
+                     Engineering (TE) Extensions to OSPF Version 2", RFC
+                     3630, September 2003.
+
+   [OSPF-V3-TE]      Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
+                     Ed., "Traffic Engineering Extensions to OSPF
+                     Version 3", RFC 5329, September 2008.
+
+   [OSPFV3]          Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
+                     "OSPF for IPv6", RFC 5340, July 2008.
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 15]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+   [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.
+
+   [RFC5250]         Berger, L., Bryskin, I., Zinin, A., and R. Coltun,
+                     "The OSPF Opaque LSA Option", RFC 5250, July 2008.
+
+8.2.  Informative References
+
+   [BGP]             Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed.,
+                     "A Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+                     January 2006.
+
+   [BRPC]            Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
+                     Roux, "A Backward Recursive PCE-Based Computation
+                     (BRPC) Procedure to Compute Shortest Inter-Domain
+                     Traffic Engineering Label Switched Paths", Work in
+                     Progress, April 2008.
+
+   [INTER-AS-TE-REQ] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS
+                     Inter-Autonomous System (AS) Traffic Engineering
+                     (TE) Requirements", RFC 4216, November 2005.
+
+   [L1VPN-OSPF-AD]   Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN
+                     Auto-Discovery", RFC 5252, July 2008.
+
+   [PCE]             Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+                     Computation Element (PCE)-Based Architecture", RFC
+                     4655, August 2006.
+
+   [PD-PATH]         Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
+                     "A Per-Domain Path Computation Method for
+                     Establishing Inter-Domain Traffic Engineering (TE)
+                     Label Switched Paths (LSPs)", RFC 5152, February
+                     2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 16]
+
+RFC 5392            OSPF Extensions for Inter-AS TE         January 2009
+
+
+Authors' Addresses
+
+   Mach(Guoyi) 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
+
+
+   Xiaodong Duan
+   China Mobile
+   53A,Xibianmennei Ave,Xunwu District
+   Beijing, China
+
+   EMail: duanxiaodong@chinamobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 17]
+