draft-ietf-ccamp-ospf-interas-te-extension-04.txt   draft-ietf-ccamp-ospf-interas-te-extension-05.txt 
Network working group M. Chen Network working group M. Chen
Internet Draft Renhai Zhang Internet Draft Renhai Zhang
Expires: October 2008 Huawei Technologies Co.,Ltd Category: Standards Track Huawei Technologies Co.,Ltd
Category: Standards Track Xiaodong Duan Created: April 14, 2008 Xiaodong Duan
China Mobile Expires: October 14, 2008 China Mobile
April 11, 2008
OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
draft-ietf-ccamp-ospf-interas-te-extension-04.txt
draft-ietf-ccamp-ospf-interas-te-extension-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 35 skipping to change at page 2, line 32
3.2. LSA Payload.............................................9 3.2. LSA Payload.............................................9
3.2.1. Link TLV...........................................9 3.2.1. Link TLV...........................................9
3.3. Sub-TLV Detail.........................................10 3.3. Sub-TLV Detail.........................................10
3.3.1. Remote AS Number Sub-TLV..........................10 3.3.1. Remote AS Number Sub-TLV..........................10
3.3.2. IPv4 Remote ASBR ID Sub-TLV.......................11 3.3.2. IPv4 Remote ASBR ID Sub-TLV.......................11
3.3.3. IPv6 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. Procedure for Inter-AS TE Links.............................12
4.1. Origin of Proxied TE Information.......................13 4.1. Origin of Proxied TE Information.......................13
5. Security Considerations.....................................14 5. Security Considerations.....................................14
6. IANA Considerations.........................................14 6. IANA Considerations.........................................14
6.1. Inter-AS TE OSPF LSA...................................15 6.1. Inter-AS TE OSPF LSA...................................14
6.1.1. Inter-AS-TE-v2 LSA................................15 6.1.1. Inter-AS-TE-v2 LSA................................14
6.1.2. Inter-AS-TE-v3 LSA................................15 6.1.2. Inter-AS-TE-v3 LSA................................14
6.2. OSPF LSA Sub-TLVs type.................................15 6.2. OSPF LSA Sub-TLVs type.................................15
7. Acknowledgments.............................................15 7. Acknowledgments.............................................15
8. References..................................................15 8. References..................................................15
8.1. Normative References...................................15 8.1. Normative References...................................15
8.2. Informative References.................................16 8.2. Informative References.................................16
Authors' Addresses.............................................17 Authors' Addresses.............................................16
Intellectual Property Statement................................17 Intellectual Property Statement................................17
Disclaimer of Validity.........................................18 Disclaimer of Validity.........................................17
Copyright Statement............................................18 Copyright Statement............................................17
1. Introduction 1. Introduction
[OSPF-TE] defines extensions to the OSPF protocol [OSPF] to support [OSPF-TE] defines extensions to the OSPF protocol [OSPF] to support
intra-area Traffic Engineering (TE). The extensions provide a way of intra-area Traffic Engineering (TE). The extensions provide a way of
encoding the TE information for TE-enabled links within the network encoding the TE information for TE-enabled links within the network
(TE links) and flooding this information within an area. Type 10 (TE links) and flooding this information within an area. Type 10
opaque Link State Advertisements (LSAs) [RFC2370] are used to carry opaque Link State Advertisements (LSAs) [RFC2370] are used to carry
such TE information. Two top-level Type Length Values (TLVs) are such TE information. Two top-level Type Length Values (TLVs) are
defined in [OSPF-TE]: Router Address TLV and Link TLV. The Link TLV defined in [OSPF-TE]: Router Address TLV and Link TLV. The Link TLV
skipping to change at page 5, line 6 skipping to change at page 5, line 4
document and [L1VPN-OSPF-AD]. document and [L1VPN-OSPF-AD].
2.2. Per-Domain Path Determination 2.2. Per-Domain Path Determination
In the per-domain method of determining an inter-AS path for an MPLS- 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 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 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 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 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 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: message to it and hence into the next AS. See Figure 1 for an
example:
R1------R3----R5-----R7------R9-----R11 R1------R3----R5-----R7------R9-----R11
| | \ | / | | | \ | / |
| | \ | ---- | | | \ | ---- |
| | \ | / | | | \ | / |
R2------R4----R6 --R8------R10----R12 R2------R4----R6 --R8------R10----R12
: : : :
<-- AS1 -->:<---- AS2 --->:<--- AS3 ---> <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 1: Inter-AS Reference Model Figure 1: Inter-AS Reference Model
skipping to change at page 12, line 39 skipping to change at page 12, line 30
included if the neighboring ASBR has an IPv6 address. If the included if the neighboring ASBR has an IPv6 address. If the
neighboring ASBR does not have an IPv6 address, the IPv4 Remote ASBR 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 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 and IPv6 Remote ASBR ID sub-TLV MAY both be present in a Link TLV in
OSPFv2 or OSPFv3. OSPFv2 or OSPFv3.
4. Procedure for Inter-AS TE Links 4. Procedure for Inter-AS TE Links
When TE is enabled on an inter-AS link and the link is up, the ASBR 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 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, [OSPF-TE]. When either the link is down or TE is disabled on the
the ASBR SHOULD withdraw the advertisement. When there are changes to link, the ASBR SHOULD withdraw the advertisement. When there are
the TE parameters for the link (for example, when the available changes to the TE parameters for the link (for example, when the
bandwidth changes) the ASBR SHOULD re-advertise the link, but the available bandwidth changes) the ASBR SHOULD re-advertise the link,
ASBR MUST take precautions against excessive re-advertisements as but the ASBR MUST take precautions against excessive
described in [OSPF-TE]. re-advertisements as described in [OSPF-TE].
Hellos MUST NOT be exchanged over the inter-AS link, and consequently, Hellos MUST NOT be exchanged over the inter-AS link, and
an OSPF adjacency MUST NOT be formed. consequently, an OSPF adjacency MUST NOT be formed.
The information advertised comes from the ASBR's knowledge of the TE The information advertised comes from the ASBR's knowledge of the TE
capabilities of the link, the ASBR's knowledge of the current status 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 and usage of the link, and configuration at the ASBR of the remote AS
number and remote ASBR TE Router ID. number and remote ASBR TE Router ID.
Legacy routers receiving an advertisement for an inter-AS TE link are Legacy routers receiving an advertisement for an inter-AS TE link are
able to ignore it because the Link Type carries an unknown value. 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 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. 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 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 link emit LSAs describing the link. The databases in the LSRs then
have two entries (one locally generated, the other from the peer) have two entries (one locally generated, the other from the peer)
that describe the different 'directions' of the link. This enables that describe the different 'directions' of the link. This enables
CSPF to do a two-way check on the link when performing path CSPF to do a two-way check on the link when performing path
computation and eliminate it from consideration unless both computation and eliminate it from consideration unless both
directions of the link satisfy the required constraints. directions of the link satisfy the required constraints.
In the case we are considering here (i.e., of a TE link to another AS) In the case we are considering here (i.e., of a TE link to another
there is, by definition, no IGP peering and hence no bi-directional AS) there is, by definition, no IGP peering and hence no
TE link information. In order for the CSPF route computation entity bi-directional TE link information. In order for the CSPF route
to include the link as a candidate path, we have to find a way to get computation entity to include the link as a candidate path, we have
LSAs describing its (bidirectional) TE properties into the TE to find a way to get LSAs describing its (bidirectional)
database. TE properties into the TE database.
This is achieved by the ASBR advertising, internally to its AS, This is achieved by the ASBR advertising, internally to its AS,
information about both directions of the TE link to the next AS. The 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; 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 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 generate an additional LSA that describes that device's 'view' of the
link. link.
Only some essential TE information for the link needs to be Only some essential TE information for the link needs to be
advertised; i.e., the Link Type, the Remote AS number and the Remote advertised; i.e., the Link Type, the Remote AS number and the Remote
skipping to change at page 16, line 34 skipping to change at page 16, line 17
8.2. Informative References 8.2. Informative References
[INTER-AS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic [INTER-AS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
Engineering Requirements", RFC4216, November 2005. Engineering Requirements", RFC4216, November 2005.
[PD-PATH] Ayyangar, A., Vasseur, JP., and Zhang, R., "A Per-domain [PD-PATH] Ayyangar, A., Vasseur, JP., and Zhang, R., "A Per-domain
path computation method for establishing Inter-domain", RFC path computation method for establishing Inter-domain", RFC
5152, February 2008. 5152, February 2008.
[BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward [BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A
Recursive PCE-based Computation (BRPC) procedure to compute Backward Recursive PCE-based Computation (BRPC) procedure
shortest inter-domain Traffic Engineering Label Switched to compute shortest inter-domain Traffic Engineering Label
Paths ", draft-ietf-pce-brpc, (work in progress) Switched Paths", draft-ietf-pce-brpc, (work in progress).
[PCE] Farrel, A., Vasseur, JP., and Ash, J., "A Path Computation [PCE] Farrel, A., Vasseur, JP., and Ash, J., "A Path Computation
Element (PCE)-Based Architecture", RFC4655, August 2006. Element (PCE)-Based Architecture", RFC4655, August 2006.
[L1VPN-OSPF-AD] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto- [L1VPN-OSPF-AD] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto-
Discovery", draft-ietf-l1vpn-ospf-auto-discovery, (work in Discovery", draft-ietf-l1vpn-ospf-auto-discovery, (work in
progress). progress).
[BGP] Rekhter, Li, Hares, "A Border Gateway Protocol 4 (BGP-4)", [BGP] Rekhter, Li, Hares, "A Border Gateway Protocol 4 (BGP-4)",
RFC4271, January 2006 RFC4271, January 2006
 End of changes. 10 change blocks. 
30 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/