< draft-ietf-teas-rsvp-rmr-extension-01.txt   draft-ietf-teas-rsvp-rmr-extension-02.txt >
TEAS WG A. Deshmukh TEAS WG A. Deshmukh
Internet-Draft K. Kompella Internet-Draft K. Kompella
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Juniper Networks, Inc.
Expires: December 30, 2018 June 28, 2018 Expires: January 9, 2020 July 8, 2019
RSVP Extensions for RMR RSVP Extensions for RMR
draft-ietf-teas-rsvp-rmr-extension-01 draft-ietf-teas-rsvp-rmr-extension-02
Abstract Abstract
Ring topology is commonly found in access and aggregation networks. Ring topology is commonly found in access and aggregation networks.
However, the use of MPLS as the transport protocol for rings is very However, the use of MPLS as the transport protocol for rings is very
limited today. draft-ietf-mpls-rmr-02 describes a mechanism to limited today. {{!I-D.ietf-mpls-rmr}} describes a mechanism to
handle rings efficiently using MPLS. This document describes the handle rings efficiently using MPLS. This document describes the
extensions to the RSVP-TE protocol for signaling MPLS label switched extensions to the RSVP-TE protocol for signaling MPLS label switched
paths in rings. paths in rings.
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.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 30, 2018. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document extends RSVP-TE [RFC3209] to establish label-switched This document extends RSVP-TE [RFC3209] to establish label-switched
path (LSP) tunnels in the ring topology. Rings are auto-discovered path (LSP) tunnels in the ring topology. Rings are auto-discovered
using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02]. using the mechanisms mentioned in the {{!I-D.ietf-mpls-rmr}}. Either
Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for auto-
auto-discovering the rings. discovering the rings.
After the rings are auto-discovered, each node in the ring knows its After the rings are auto-discovered, each node in the ring knows its
clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring
links. All of the express links in the ring also get identified as links. All of the express links in the ring also get identified as
part of the auto-discovery process. At this point, every node in the part of the auto-discovery process. At this point, every node in the
ring informs the RSVP protocol to begin the signaling of the ring ring informs the RSVP protocol to begin the signaling of the ring
LSPs. LSPs.
Section 2 covers the terminology used in this document. Section 3 Section 2 covers the terminology used in this document. Section 3
presents the RSVP protocol extensions needed to support MPLS rings. presents the RSVP protocol extensions needed to support MPLS rings.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
define the ring direction of the corresponding Path message. define the ring direction of the corresponding Path message.
ClockWise(CW) Direction 0x01: This flag indicates that the ClockWise(CW) Direction 0x01: This flag indicates that the
corresponding Path message is traveling in the ClockWise(CW) corresponding Path message is traveling in the ClockWise(CW)
direction along the ring. direction along the ring.
Anti-ClockWise(AC) Direction 0x02: This flag indicates that the Anti-ClockWise(AC) Direction 0x02: This flag indicates that the
corresponding Path message is traveling in the Anti-ClockWise(AC) corresponding Path message is traveling in the Anti-ClockWise(AC)
direction along the ring. direction along the ring.
Express Link 0x04: This flag indicates that the corresponding Path
message is traveling along the Express link in the ring.
3.2. SENDER_TEMPLATE,FILTER_SPEC Objects 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects
There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC
objects. The format of the above 2 objects will be similar to the objects. The format of the above 2 objects will be similar to the
definitions in RFC 3209. [RFC3209] Only the semantics of these definitions in RFC 3209. [RFC3209] Only the semantics of these
objects will slightly change. This will be explained in section objects will slightly change. This will be explained in section
Section 4.6 below. Section 4.6 below.
4. Ring Signaling Procedures 4. Ring Signaling Procedures
skipping to change at page 8, line 48 skipping to change at page 8, line 48
4.2.2. Resv Processing for RMR 4.2.2. Resv Processing for RMR
When Egress node R0 receives the modified Path message, it replies When Egress node R0 receives the modified Path message, it replies
with the a Resv message containing multiple FLOW_DESCRIPTOR objects. with the a Resv message containing multiple FLOW_DESCRIPTOR objects.
There should be 1 FLOW_DESCRIPTOR object corresponding to each of the There should be 1 FLOW_DESCRIPTOR object corresponding to each of the
SENDER_TEMPLATE object in the incoming Path message. The SESSION SENDER_TEMPLATE object in the incoming Path message. The SESSION
object of the Resv message will exactly match with the received Path object of the Resv message will exactly match with the received Path
message. message.
[RFC 3209] already supports receiving a Resv message with multiple RFC 3209[RFC3209] already supports receiving a Resv message with
flow-descriptors in it, as described in section 3.2 in that document. multiple flow-descriptors in it, as described in section 3.2 in that
In each flow-descriptor there is a separate: document. In each flow-descriptor there is a separate:
a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent
in the Path message which could be admitted after admission-control in the Path message which could be admitted after admission-control
downstream, and downstream, and
b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent
in the Path message that could be admitted after admission-control in the Path message that could be admitted after admission-control
downstream. downstream.
Each transit node removes the FLOW-DESCRIPTOR corresponding to itself Each transit node removes the FLOW-DESCRIPTOR corresponding to itself
skipping to change at page 11, line 29 skipping to change at page 11, line 29
For the ring links which are common between the old and new LSPs, the For the ring links which are common between the old and new LSPs, the
LSPs will share resources(SE style reservation) on those ring links. LSPs will share resources(SE style reservation) on those ring links.
Note that here we are using Ring Instance ID in the SESSION object to Note that here we are using Ring Instance ID in the SESSION object to
share resources instead of the LSP_ID in the SENDER_TEMPLATE share resources instead of the LSP_ID in the SENDER_TEMPLATE
Object(which is used in RSVP-TE for sharing resources as described in Object(which is used in RSVP-TE for sharing resources as described in
RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different
functionality as described in section Section 4.6. functionality as described in section Section 4.6.
4.5. Express Links 4.5. Express Links
The details for signaling over express links will be given in a Express links are discovered once ring nodes, ring links and
future version. directions have been established. As defined earlier, express links
are links joining non-neighboring ring nodes. Express links are both
clockwise and anti-clockwise.
A ring node with an Express link replicates the incoming Path message
over the Express link. The "Express Link" flag is set in the SESSION
object of the replicated Path message. Also, the ring node Ri
includes an additional SENDER_DESCRIPTOR with a new LSP_ID in the
outgoing PATH message.
When this Path message with Express link flag is received at the
other end of Express link, the other ring node replies with the Resv
message. It does not forward this Path message to any of it's ring
neighbors. Thus, the "Express" LSPs are effectively 1 hop LSPs
formed over the "Express Links".
4.6. Bandwidth management 4.6. Bandwidth management
For RSVP-TE LSPs, bandwidths may be signaled in both directions. For RSVP-TE LSPs, bandwidths may be signaled in both directions.
However, these are not provisioned either; rather, one does "reverse However, these are not provisioned either; rather, one does "reverse
call admission control". When a service needs to use an LSP, the call admission control". When a service needs to use an LSP, the
ring node where the traffic enters the ring attempts to increase the ring node where the traffic enters the ring attempts to increase the
bandwidth on the LSP to the egress. If successful, the service is bandwidth on the LSP to the egress. If successful, the service is
admitted to the ring. admitted to the ring.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
7. IANA Considerations 7. IANA Considerations
Requests to IANA will be made in a future version of this document. Requests to IANA will be made in a future version of this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mpls-rmr] [I-D.ietf-mpls-rmr]
Kompella, K. and L. Contreras, "Resilient MPLS Rings", Kompella, K. and L. Contreras, "Resilient MPLS Rings",
draft-ietf-mpls-rmr-07 (work in progress), March 2018. draft-ietf-mpls-rmr-11 (work in progress), June 2019.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 10 change blocks. 
14 lines changed or deleted 31 lines changed or added

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