< draft-ietf-pce-pcep-domain-sequence-09.txt | draft-ietf-pce-pcep-domain-sequence-10.txt > | |||
---|---|---|---|---|
PCE Working Group D. Dhody | PCE Working Group D. Dhody | |||
Internet-Draft U. Palle | Internet-Draft U. Palle | |||
Intended status: Experimental Huawei Technologies | Intended status: Experimental Huawei Technologies | |||
Expires: March 23, 2016 R. Casellas | Expires: May 16, 2016 R. Casellas | |||
CTTC | CTTC | |||
September 20, 2015 | November 13, 2015 | |||
Standard Representation of Domain-Sequence | Domain Subobjects for Path Computation Element (PCE) Communication | |||
draft-ietf-pce-pcep-domain-sequence-09 | Protocol (PCEP). | |||
draft-ietf-pce-pcep-domain-sequence-10 | ||||
Abstract | Abstract | |||
The ability to compute shortest constrained Traffic Engineering Label | The ability to compute shortest constrained Traffic Engineering Label | |||
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and | Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and | |||
Generalized MPLS (GMPLS) networks across multiple domains has been | Generalized MPLS (GMPLS) networks across multiple domains has been | |||
identified as a key requirement. In this context, a domain is a | identified as a key requirement. In this context, a domain is a | |||
collection of network elements within a common sphere of address | collection of network elements within a common sphere of address | |||
management or path computational responsibility such as an Interior | management or path computational responsibility such as an Interior | |||
Gateway Protocol (IGP) area or an Autonomous System (AS). This | Gateway Protocol (IGP) area or an Autonomous System (AS). This | |||
document specifies a standard representation and encoding of a | document specifies a representation and encoding of a Domain- | |||
Domain-Sequence, which is defined as an ordered sequence of domains | Sequence, which is defined as an ordered sequence of domains | |||
traversed to reach the destination domain to be used by Path | traversed to reach the destination domain to be used by Path | |||
Computation Elements (PCEs) to compute inter-domain constrained | Computation Elements (PCEs) to compute inter-domain constrained | |||
shortest paths across a predetermined sequence of domains . This | shortest paths across a predetermined sequence of domains . This | |||
document also defines new subobjects to be used to encode domain | document also defines new subobjects to be used to encode domain | |||
identifiers. | identifiers. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 45 | skipping to change at page 1, line 46 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 23, 2016. | This Internet-Draft will expire on May 16, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 25 | skipping to change at page 2, line 25 | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6 | 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 | 3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 | |||
3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 | 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 | |||
3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 | 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 | 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 | |||
3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9 | 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9 | |||
3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 | 3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 | |||
3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 | 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 | |||
3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11 | 3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11 | |||
3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11 | 3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11 | |||
3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 | 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 | |||
3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 | 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 13 | |||
3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13 | 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13 | |||
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 | 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 14 | |||
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15 | 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15 | |||
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 15 | 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 16 | |||
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16 | 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16 | |||
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18 | 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18 | |||
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 | 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 | |||
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 | 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 | |||
4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23 | 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23 | |||
4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 | 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 | |||
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 24 | 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 26 | |||
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 | 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 26 | |||
5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 25 | 5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 26 | |||
5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 25 | 5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 26 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 26 | 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 27 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
8. Manageability Considerations . . . . . . . . . . . . . . . . 26 | 8. Manageability Considerations . . . . . . . . . . . . . . . . 28 | |||
8.1. Control of Function and Policy . . . . . . . . . . . . . 26 | 8.1. Control of Function and Policy . . . . . . . . . . . . . 28 | |||
8.2. Information and Data Models . . . . . . . . . . . . . . . 27 | 8.2. Information and Data Models . . . . . . . . . . . . . . . 28 | |||
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 | 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 | |||
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 | 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 | |||
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 | 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 29 | |||
8.6. Impact On Network Operations . . . . . . . . . . . . . . 27 | 8.6. Impact On Network Operations . . . . . . . . . . . . . . 29 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 29 | 10.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
1. Introduction | 1. Introduction | |||
A Path Computation Element (PCE) may be used to compute end-to-end | A Path Computation Element (PCE) may be used to compute end-to-end | |||
paths across multi-domain environments using a per-domain path | paths across multi-domain environments using a per-domain path | |||
computation technique [RFC5152]. The backward recursive path | computation technique [RFC5152]. The backward recursive path | |||
computation (BRPC) mechanism [RFC5441] also defines a PCE-based path | computation (BRPC) mechanism [RFC5441] also defines a PCE-based path | |||
computation procedure to compute inter-domain constrained path for | computation procedure to compute inter-domain constrained path for | |||
(G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume | (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume | |||
that the sequence of domains to be crossed from source to destination | that the sequence of domains to be crossed from source to destination | |||
skipping to change at page 4, line 20 | skipping to change at page 4, line 20 | |||
[DOMAIN-SUBOBJ]. | [DOMAIN-SUBOBJ]. | |||
1.1. Scope | 1.1. Scope | |||
The procedures described in this document are experimental. The | The procedures described in this document are experimental. The | |||
experiment is intended to enable research for the usage of Domain- | experiment is intended to enable research for the usage of Domain- | |||
Sequence at the PCEs for inter-domain paths. For this purpose this | Sequence at the PCEs for inter-domain paths. For this purpose this | |||
document specifies new domain subobjects as well as how they | document specifies new domain subobjects as well as how they | |||
incorporate with existing subobjects to represent a Domain-Sequence. | incorporate with existing subobjects to represent a Domain-Sequence. | |||
The experiment will end two years after the RFC is published. At | ||||
that point, the RFC authors will attempt to determine how widely this | ||||
has been implemented and deployed. | ||||
This document does not change the procedures for handling existing | This document does not change the procedures for handling existing | |||
subobjects in PCEP. | subobjects in PCEP. | |||
The new subobjects introduced by this document will not be understood | The new subobjects introduced by this document will not be understood | |||
by a legacy implementation. If one of the subobjects is received in | by a legacy implementation. If one of the subobjects is received in | |||
a PCEP object that does not understand it, it will behave as | a PCEP object that does not understand it, it will behave as | |||
described in Section 3.4.3. Therefore, it is assumed that this | described in Section 3.4.3. Therefore, it is assumed that this | |||
experiment will be conducted only when both the PCE and the PCC form | experiment will be conducted only when both the PCE and the PCC form | |||
part of the experiment. It is possible that a PCC or PCE can operate | part of the experiment. It is possible that a PCC or PCE can operate | |||
with peers some of which form part of the experiment and some that do | with peers some of which form part of the experiment and some that do | |||
skipping to change at page 12, line 38 | skipping to change at page 12, line 38 | |||
that has this link. | that has this link. | |||
* Otherwise, it assumes that the subobject belongs to the current | * Otherwise, it assumes that the subobject belongs to the current | |||
Area. | Area. | |||
o In case the current PCE is not responsible for the path | o In case the current PCE is not responsible for the path | |||
computation in the current AS or Area, then the PCE selects the | computation in the current AS or Area, then the PCE selects the | |||
"next PCE" in the domain-sequence based on the current AS and | "next PCE" in the domain-sequence based on the current AS and | |||
Area. | Area. | |||
Note that it is advised that, PCC should use AS and Area subobject | ||||
while building the domain-sequence in IRO and avoid using other | ||||
mechanism to change the "current AS" and "current Area" as described | ||||
above. | ||||
3.5. Exclude Route Object (XRO) | 3.5. Exclude Route Object (XRO) | |||
The Exclude Route Object (XRO) [RFC5521] is an optional object used | The Exclude Route Object (XRO) [RFC5521] is an optional object used | |||
to specify exclusion of certain abstract nodes or resources from the | to specify exclusion of certain abstract nodes or resources from the | |||
whole path. | whole path. | |||
3.5.1. Subobjects | 3.5.1. Subobjects | |||
Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], | Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], | |||
[RFC4874], and [RFC5520], but new subobjects related to Domain- | [RFC4874], and [RFC5520], but new subobjects related to Domain- | |||
skipping to change at page 15, line 10 | skipping to change at page 15, line 19 | |||
All other fields are consistent with the definition in Section 3.4. | All other fields are consistent with the definition in Section 3.4. | |||
All the processing rules are as per [RFC5521]. | All the processing rules are as per [RFC5521]. | |||
Note that, if a PCE receives an XRO in a PCReq message that contains | Note that, if a PCE receives an XRO in a PCReq message that contains | |||
subobjects defined in this document, that it does not recognize, it | subobjects defined in this document, that it does not recognize, it | |||
will respond according to the rules for a malformed object as per | will respond according to the rules for a malformed object as per | |||
[RFC5440]. | [RFC5440]. | |||
IGP Area subobjects in the XRO are local to the current AS. In case | ||||
of multi-AS path computation to exclude an IGP area in a different | ||||
AS, IGP Area subobject should be part of Explicit Exclusion Route | ||||
Subobject (EXRS) in the IRO to specify the AS in which the IGP area | ||||
is to be excluded. Further policy may be applied to prune/ignore | ||||
Area subobjects in XRO after "current AS" change during path | ||||
computation. | ||||
3.6. Explicit Exclusion Route Subobject (EXRS) | 3.6. Explicit Exclusion Route Subobject (EXRS) | |||
Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to | EXRS [RFC5521] is used to specify exclusion of certain abstract nodes | |||
specify exclusion of certain abstract nodes between a specific pair | between a specific pair of nodes. | |||
of nodes. | ||||
The EXRS subobject can carry any of the subobjects defined for | The EXRS subobject can carry any of the subobjects defined for | |||
inclusion in the XRO, thus the new subobjects to support 4 byte AS | inclusion in the XRO, thus the new subobjects to support 4 byte AS | |||
and IGP (OSPF / ISIS) Area can also be used in the EXRS. The | and IGP (OSPF / ISIS) Area can also be used in the EXRS. The | |||
meanings of the fields of the new XRO subobjects are unchanged when | meanings of the fields of the new XRO subobjects are unchanged when | |||
the subobjects are included in an EXRS, except that scope of the | the subobjects are included in an EXRS, except that scope of the | |||
exclusion is limited to the single hop between the previous and | exclusion is limited to the single hop between the previous and | |||
subsequent elements in the IRO. | subsequent elements in the IRO. | |||
The EXRS subobject should be interpreted in the context of the | The EXRS subobject should be interpreted in the context of the | |||
skipping to change at page 18, line 7 | skipping to change at page 18, line 7 | |||
| +--+ | | | | | | | +--+ | | | | | | |||
| | | +--+ | | | | | +--+ | | |||
| | | | | | | | | | |||
| Area 1 | | Area 5 | | | Area 1 | | Area 5 | | |||
----------------- ------------------ | ----------------- ------------------ | |||
Figure 1: Inter-Area Path Computation | Figure 1: Inter-Area Path Computation | |||
AS Number is 100. | AS Number is 100. | |||
This could be represented in the IRO as: | If the ingress is in Area 2, egress in Area 4 and transit through | |||
Area 0. Some possible way a PCC can encode the IRO: | ||||
+---------+ +---------+ +---------+ | +---------+ +---------+ +---------+ | |||
|IRO | |Sub | |Sub | | |IRO | |Sub | |Sub | | |||
|Object | |Object | |Object | | |Object | |Object | |Object | | |||
|Header | |Area 0 | |Area 4 | | |Header | |Area 0 | |Area 4 | | |||
| | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | |||
+---------+ +---------+ +---------+ | +---------+ +---------+ +---------+ | |||
or | or | |||
skipping to change at page 19, line 32 | skipping to change at page 19, line 32 | |||
\ / / | \ / / | |||
A3----------D1---D2---D3---------C3 | A3----------D1---D2---D3---------C3 | |||
<----------> | <----------> | |||
AS D | AS D | |||
* All AS have one area (area 0) | * All AS have one area (area 0) | |||
Figure 2: Inter-AS Path Computation | Figure 2: Inter-AS Path Computation | |||
This could be represented in the IRO as: | If the ingress is in AS A, egress in AS C and transit through AS B. | |||
Some possible way a PCC can encode the IRO: | ||||
+-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ | |||
|IRO | |Sub | |Sub | | |IRO | |Sub | |Sub | | |||
|Object | |Object | |Object | | |Object | |Object | |Object | | |||
|Header | |AS B | |AS C | | |Header | |AS B | |AS C | | |||
| | | | | | | | | | | | | | |||
+-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ | |||
or | or | |||
skipping to change at page 22, line 32 | skipping to change at page 22, line 32 | |||
| | +--+ | | | | | | +--+ | | | | |||
| | | | | | | | | | | | |||
| +------------+ +----------------+ | | +------------+ +----------------+ | |||
| | | | |||
| | | | |||
AS 100 | AS 200 | AS 100 | AS 200 | |||
| | | | |||
Figure 3: Inter-AS Path Computation | Figure 3: Inter-AS Path Computation | |||
The Domain-Sequence for the LSP (A-B) can be carried in the IRO as | For LSP (A-B), where ingress A is in (AS 100, Area 0), egress B in | |||
shown below: | (AS 200, Area 4) and transit through (AS 200, Area 0). Some possible | |||
way a PCC can encode the IRO: | ||||
+-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ | |||
|IRO | |Sub | |Sub | |Sub | | |IRO | |Sub | |Sub | |Sub | | |||
|Object | |Object | |Object | |Object | | |Object | |Object | |Object | |Object | | |||
|Header | |AS 200 | |Area 0 | |Area 4 | | |Header | |AS 200 | |Area 0 | |Area 4 | | |||
| | | | | | | | | | | | | | | | | | |||
+-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ | |||
or | or | |||
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | |||
|IRO | |Sub | |Sub | |Sub | |Sub | |Sub | | |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | | |||
|Object | |Object | |Object | |Object | |Object | |Object | | |Object | |Object | |Object | |Object | |Object | |Object | | |||
|Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 | | |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 | | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | |||
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | |||
The Domain-Sequence for the LSP (A-C) can be carried in the IRO as | For LSP (A-C), where ingress A is in (AS 100, Area 0), egress C in | |||
shown below: | (AS 200, Area 5) and transit through (AS 200, Area 0). Some possible | |||
way a PCC can encode the IRO: | ||||
+-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ | |||
|IRO | |Sub | |Sub | |Sub | | |IRO | |Sub | |Sub | |Sub | | |||
|Object | |Object | |Object | |Object | | |Object | |Object | |Object | |Object | | |||
|Header | |AS 200 | |Area 0 | |Area 5 | | |Header | |AS 200 | |Area 0 | |Area 5 | | |||
| | | | | | | | | | | | | | | | | | |||
+-------+ +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+ +-------+ | |||
or | or | |||
skipping to change at page 24, line 27 | skipping to change at page 25, line 5 | |||
A PCE which can support adjacent domains can internally handle those | A PCE which can support adjacent domains can internally handle those | |||
domains in the Domain-Sequence without any impact on the other | domains in the Domain-Sequence without any impact on the other | |||
domains in the Domain-Sequence. | domains in the Domain-Sequence. | |||
4.5. P2MP | 4.5. P2MP | |||
[RFC7334] describes an experimental inter-domain P2MP path | [RFC7334] describes an experimental inter-domain P2MP path | |||
computation mechanism where the path domain tree is described as a | computation mechanism where the path domain tree is described as a | |||
series of Domain-Sequences, an example is shown in the below figure: | series of Domain-Sequences, an example is shown in the below figure: | |||
D1-D3-D6, D1-D3-D5 and D1-D2-D4. | +----------------+ | |||
D1 | | |Domain D1 | |||
/ \ | | R | | |||
D2 D3 | | | | |||
/ / \ | | A | | |||
D4 D5 D6 | | | | |||
+-B------------C-+ | ||||
/ \ | ||||
/ \ | ||||
/ \ | ||||
Domain D2 / \ Domain D3 | ||||
+-------------D--+ +-----E----------+ | ||||
| | | | | ||||
| F | | | | ||||
| G | | H | | ||||
| | | | | ||||
| | | | | ||||
+-I--------------+ +-J------------K-+ | ||||
/\ / \ | ||||
/ \ / \ | ||||
/ \ / \ | ||||
/ \ / \ | ||||
/ \ / \ | ||||
/ \ / \ | ||||
/ Domain D4 \ Domain D5 / Domain D6 \ | ||||
+-L-------------W+ +------P---------+ +-----------T----+ | ||||
| | | | | | | ||||
| | | Q | | U | | ||||
| M O | | S | | | | ||||
| | | | | V | | ||||
| N | | R | | | | ||||
+----------------+ +----------------+ +----------------+ | ||||
The domain tree can be represented as a series of domain-sequence - | ||||
o Domian D1, Domian D3, Domian D6 | ||||
o Domian D1, Domian D3, Domian D5 | ||||
o Domian D1, Domian D2, Domian D4 | ||||
The domain sequence handling described in this document could be | The domain sequence handling described in this document could be | |||
applied to P2MP path domain tree. | applied to P2MP path domain tree. | |||
4.6. Hierarchical PCE | 4.6. Hierarchical PCE | |||
In case of H-PCE [RFC6805], the parent PCE can be requested to | In case of H-PCE [RFC6805], the parent PCE can be requested to | |||
determine the Domain-Sequence and return it in the path computation | determine the Domain-Sequence and return it in the path computation | |||
reply, using the ERO. . For the example in section 4.6 of [RFC6805], | reply, using the ERO. . For the example in section 4.6 of [RFC6805], | |||
the Domain-Sequence can possibly appear as: | the Domain-Sequence can possibly appear as: | |||
skipping to change at page 26, line 22 | skipping to change at page 27, line 27 | |||
o "IRO Subobjects": http://www.iana.org/assignments/pcep/ | o "IRO Subobjects": http://www.iana.org/assignments/pcep/ | |||
pcep.xhtml#iro-subobject | pcep.xhtml#iro-subobject | |||
o "XRO Subobjects": http://www.iana.org/assignments/pcep/ | o "XRO Subobjects": http://www.iana.org/assignments/pcep/ | |||
pcep.xhtml#xro-subobject | pcep.xhtml#xro-subobject | |||
Upon approval of this document, IANA is requested to make identical | Upon approval of this document, IANA is requested to make identical | |||
additions to these registries as follows: | additions to these registries as follows: | |||
Subobject Type Reference | Subobject Type Reference | |||
TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ] | TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ] | |||
TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ] | TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ] | |||
TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ] | TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ] | |||
Further upon approval of this document, IANA is requested to add a | ||||
reference to this document to the new RSVP numbers that are | ||||
registered by [DOMAIN-SUBOBJ]. | ||||
7. Security Considerations | 7. Security Considerations | |||
This document specifies a standard representation of Domain-Sequence | The protocol extensions defined in this document do not substantially | |||
and new subobjects, which could be used in inter-domain PCE scenarios | change the nature of PCEP. Therefore, the security considerations | |||
as explained in other RFC and drafts. The new subobjects and Domain- | set out in [RFC5440] apply unchanged. Note that further security | |||
Sequence mechanisms defined in this document allow finer and more | considerations for the use of PCEP over TCP are presented in | |||
specific control of the path computed by a cooperating PCE(s). Such | [RFC6952]. | |||
control increases the risk if a PCEP message is intercepted, | ||||
modified, or spoofed because it allows the attacker to exert control | This document specifies a representation of Domain-Sequence and new | |||
over the path that the PCE will compute or to make the path | subobjects, which could be used in inter-domain PCE scenarios as | |||
computation impossible. Therefore, the security techniques described | explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334] etc. The | |||
in [RFC5440] are considered more important. | security considerations set out in each of these mechanisms remain | |||
unchanged by the new subobjects and Domain-Sequence representation in | ||||
this document. | ||||
But the new subobjects do allow finer and more specific control of | ||||
the path computed by a cooperating PCE(s). Such control increases | ||||
the risk if a PCEP message is intercepted, modified, or spoofed | ||||
because it allows the attacker to exert control over the path that | ||||
the PCE will compute or to make the path computation impossible. | ||||
Consequently, it is important that implementations conform to the | ||||
relevant security requirements of [RFC5440]. These mechanisms | ||||
include: | ||||
o Securing the PCEP session messages using TCP security techniques | ||||
(Section 10.2 of [RFC5440]). PCEP implementations SHOULD also | ||||
consider the additional security provided by the TCP | ||||
Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. | ||||
o Authenticating the PCEP messages to ensure the message is intact | ||||
and sent from an authorized node (Section 10.3 of [RFC5440]). | ||||
o PCEP operates over TCP, so it is also important to secure the PCE | ||||
and PCC against TCP denial-of-service attacks. Section 10.7.1 of | ||||
[RFC5440] outlines a number of mechanisms for minimizing the risk | ||||
of TCP-based denial-of-service attacks against PCEs and PCCs. | ||||
o In inter-AS scenarios, attacks may be particularly significant | ||||
with commercial as well as service-level implications. | ||||
Note, however, that the Domain-Sequence mechanisms also provide the | Note, however, that the Domain-Sequence mechanisms also provide the | |||
operator with the ability to route around vulnerable parts of the | operator with the ability to route around vulnerable parts of the | |||
network and may be used to increase overall network security. | network and may be used to increase overall network security. | |||
8. Manageability Considerations | 8. Manageability Considerations | |||
8.1. Control of Function and Policy | 8.1. Control of Function and Policy | |||
The exact behaviour with regards to desired inclusion and exclusion | The exact behaviour with regards to desired inclusion and exclusion | |||
skipping to change at page 28, line 15 | skipping to change at page 30, line 7 | |||
9. Acknowledgments | 9. Acknowledgments | |||
Authors would like to especially thank Adrian Farrel for his detailed | Authors would like to especially thank Adrian Farrel for his detailed | |||
reviews as well as providing text to be included in the document. | reviews as well as providing text to be included in the document. | |||
Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin | Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin | |||
Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, | Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, | |||
Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti | Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti | |||
and Jonathan Hardwick for their useful comments and suggestions. | and Jonathan Hardwick for their useful comments and suggestions. | |||
Thanks to Jonathan Hardwick for shperding this document. | ||||
Thanks to Joel Halpern for Gen-ART Review. | ||||
Thanks to Klaas Wierenga for SecDir Review. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
skipping to change at page 29, line 31 | skipping to change at page 31, line 31 | |||
[IRO-UPDATE] | [IRO-UPDATE] | |||
Dhody, D., "Update to Include Route Object (IRO) | Dhody, D., "Update to Include Route Object (IRO) | |||
specification in Path Computation Element communication | specification in Path Computation Element communication | |||
Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015. | Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015. | |||
[DOMAIN-SUBOBJ] | [DOMAIN-SUBOBJ] | |||
Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, | Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, | |||
"Domain Subobjects for Resource ReserVation Protocol - | "Domain Subobjects for Resource ReserVation Protocol - | |||
Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- | Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- | |||
domain-subobjects-02)", July 2015. | domain-subobjects-04)", November 2015. | |||
10.2. Informative References | 10.2. Informative References | |||
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation | [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation | |||
Element (PCE)-Based Architecture", RFC 4655, | Element (PCE)-Based Architecture", RFC 4655, | |||
DOI 10.17487/RFC4655, August 2006, | DOI 10.17487/RFC4655, August 2006, | |||
<http://www.rfc-editor.org/info/rfc4655>. | <http://www.rfc-editor.org/info/rfc4655>. | |||
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for | [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for | |||
Inter-Domain Multiprotocol Label Switching Traffic | Inter-Domain Multiprotocol Label Switching Traffic | |||
skipping to change at page 30, line 22 | skipping to change at page 32, line 22 | |||
"Preserving Topology Confidentiality in Inter-Domain Path | "Preserving Topology Confidentiality in Inter-Domain Path | |||
Computation Using a Path-Key-Based Mechanism", RFC 5520, | Computation Using a Path-Key-Based Mechanism", RFC 5520, | |||
DOI 10.17487/RFC5520, April 2009, | DOI 10.17487/RFC5520, April 2009, | |||
<http://www.rfc-editor.org/info/rfc5520>. | <http://www.rfc-editor.org/info/rfc5520>. | |||
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of | [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of | |||
Monitoring Tools for Path Computation Element (PCE)-Based | Monitoring Tools for Path Computation Element (PCE)-Based | |||
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, | Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, | |||
<http://www.rfc-editor.org/info/rfc5886>. | <http://www.rfc-editor.org/info/rfc5886>. | |||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | ||||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | ||||
June 2010, <http://www.rfc-editor.org/info/rfc5925>. | ||||
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | |||
Autonomous System (AS) Number Space", RFC 6793, | Autonomous System (AS) Number Space", RFC 6793, | |||
DOI 10.17487/RFC6793, December 2012, | DOI 10.17487/RFC6793, December 2012, | |||
<http://www.rfc-editor.org/info/rfc6793>. | <http://www.rfc-editor.org/info/rfc6793>. | |||
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | ||||
BGP, LDP, PCEP, and MSDP Issues According to the Keying | ||||
and Authentication for Routing Protocols (KARP) Design | ||||
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, | ||||
<http://www.rfc-editor.org/info/rfc6952>. | ||||
[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, | [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, | |||
"PCE-Based Computation Procedure to Compute Shortest | "PCE-Based Computation Procedure to Compute Shortest | |||
Constrained Point-to-Multipoint (P2MP) Inter-Domain | Constrained Point-to-Multipoint (P2MP) Inter-Domain | |||
Traffic Engineering Label Switched Paths", RFC 7334, | Traffic Engineering Label Switched Paths", RFC 7334, | |||
DOI 10.17487/RFC7334, August 2014, | DOI 10.17487/RFC7334, August 2014, | |||
<http://www.rfc-editor.org/info/rfc7334>. | <http://www.rfc-editor.org/info/rfc7334>. | |||
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. | [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. | |||
Hardwick, "Path Computation Element Communication Protocol | Hardwick, "Path Computation Element Communication Protocol | |||
(PCEP) Management Information Base (MIB) Module", | (PCEP) Management Information Base (MIB) Module", | |||
RFC 7420, DOI 10.17487/RFC7420, December 2014, | RFC 7420, DOI 10.17487/RFC7420, December 2014, | |||
<http://www.rfc-editor.org/info/rfc7420>. | <http://www.rfc-editor.org/info/rfc7420>. | |||
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure | ||||
Transport for PCEP", draft-ietf-pce-pceps-05 (work in | ||||
progress), November 2015. | ||||
Authors' Addresses | Authors' Addresses | |||
Dhruv Dhody | Dhruv Dhody | |||
Huawei Technologies | Huawei Technologies | |||
Divyashree Techno Park, Whitefield | Divyashree Techno Park, Whitefield | |||
Bangalore, Karnataka 560037 | Bangalore, Karnataka 560037 | |||
India | India | |||
EMail: dhruv.ietf@gmail.com | EMail: dhruv.ietf@gmail.com | |||
Udayasree Palle | Udayasree Palle | |||
Huawei Technologies | Huawei Technologies | |||
Divyashree Techno Park, Whitefield | Divyashree Techno Park, Whitefield | |||
Bangalore, Karnataka 560037 | Bangalore, Karnataka 560037 | |||
India | India | |||
EMail: udayasree.palle@huawei.com | EMail: udayasree.palle@huawei.com | |||
Ramon Casellas | Ramon Casellas | |||
CTTC | CTTC | |||
End of changes. 28 change blocks. | ||||
60 lines changed or deleted | 167 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |