Pre-standard Linear Protection Switching in MPLS-TP
draft-zulr-mpls-tp-linear-protection-switching-11
The information below is for an old version of the document.
draft-zulr-mpls-tp-linear-protection-switching-11
Network Working Group J. Halpern, Ed.
Internet-Draft Ericsson
Intended status: Informational C. Pignataro, Ed.
Expires: January 25, 2016 Cisco
July 24, 2015
Service Function Chaining (SFC) Architecture
draft-ietf-sfc-architecture-10
Abstract
This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFC) in
a network. It includes architectural concepts, principles, and
components used in the construction of composite services through
deployment of SFCs, with a focus on those to be standardized in the
IETF. This document does not propose solutions, protocols, or
extensions to existing protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 25, 2016.
Copyright Notice
Copyright (c) 2015 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. Code Components extracted from this document must
Halpern & Pignataro Expires January 25, 2016 [Page 1]
Internet-Draft SFC Architecture July 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 7
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 7
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 8
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 9
2.3.1. Service Function Chains, Service Function Paths, and
Rendered Service Path . . . . . . . . . . . . . . . . 10
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 11
4. Core SFC Architecture Components . . . . . . . . . . . . . . 12
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 13
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 14
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 14
4.3.1. Transport Derived SFF . . . . . . . . . . . . . . . . 16
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 16
4.5. Network Overlay and Network Components . . . . . . . . . 17
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 18
4.8. Re-Classification and Branching . . . . . . . . . . . . . 18
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 19
5. Additional Architectural Concepts . . . . . . . . . . . . . . 19
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 19
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 20
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 21
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 22
5.5. Load Balancing Considerations . . . . . . . . . . . . . . 22
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 23
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. Contributors and Acknowledgments . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
The delivery of end-to-end services often requires various service
functions. These include traditional network service functions such
as firewalls and traditional IP Network Address Translators (NATs),
Halpern & Pignataro Expires January 25, 2016 [Page 2]
Internet-Draft SFC Architecture July 2015
as well as application-specific functions. The definition and
instantiation of an ordered set of service functions and subsequent
&
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
request and the state machine table for far end requests are used
to calculate the final state.
o If the highest local request is neither Clear, nor clearance of SF
or of SD, nor expiration of WTR, the APS process logic compares
the highest local request with the request of the last received
"Request/State" information based on Figure 6.
1. If the highest local request has higher or equal priority, it
is used with the state transition table for local requests
defined in Section 9 to determine the final state; otherwise
2. The request of the last received "Request/State" information
is used with the state transition table for far end requests
defined in Section 9 to determine the final state.
The "APS message generator" generates APS specific information with
the signaled APS information for the final state from the state
transition calculation (with coding as described in Figure 5).
8.2. Equal priority requests
In general, once a switch has been completed due to a request, it
will not be overridden by another request of the same priority
(first-come, first-served policy). Equal priority requests from both
sides of a bidirectional protection group are both considered valid,
as follows:
o If the local state is NR, with the requested signal number 1, and
the far-end state is NR, with the requested signal number 0, the
local state transits to NR with the requested signal number 0.
This applies to the case when the remote request for switching to
the protection transport entity has been cleared.
o If both the local and far-end states are NR, with the requested
signal number 1, the local state transits to the appropriate new
state (DNR state for non-revertive mode and WTR state for
revertive mode). This applies to the case when the old request
has been cleared at both ends.
o If both the local and far-end states are RR, with the same
requested signal number, both ends transit to the appropriate new
state according to the requested signal number. This applies to
the case of concurrent deactivation of EXER from both ends.
o In other cases, no state transition occurs, even if equal priority
requests are activated from both ends. Note that if MSs are
issued simultaneously to both working and protection transport
van Helvoort, et al. Expires August 17, 2014 [Page 21]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
entities, either as local or far-end requests, the MS to the
working transport entity is considered as having higher priority
than the MS to the protection transport entity.
8.3. Signal degrade of the protection transport entity
Signal degrade on protection transport entity has the same priority
as signal degrade on working transport entity. As a result, if an SD
condition affects both transport entities, the first SD detected MUST
NOT overridden by the second SD detected. If the SD is detected
simultaneously, either as local or far-end requests on both working
and protection transport entities, then the SD on the standby
transport entity MUST be considered as having higher priority than
the SD on the active transport entity, and the normal traffic signal
continues to be selected from the active transport entity (i.e., no
unnecessary protection switching is performed).
In the preceding sentence, "simultaneously" relates to the occurrence
of SD on both the active and standby transport entities at input to
the protection switching process at the same time, or as long as a SD
request has not been acknowledged by the remote end in bidirectional
protection switching.
9. Protection switching state transition table
In this section, state transition tables for the following protection
switching configurations are described.
o 1:1 bidirectional (revertive mode, non-revertive mode);
o 1+1 bidirectional (revertive mode, non-revertive mode);
o 1+1 unidirectional (revertive mode, non-revertive mode).
Note that any other global or local request which is not described in
state transition tables does not trigger any state transition.
The states specified in the state transition tables can be described
as follows:
o NR: NR is the state entered by the local priority under all
conditions where no local protection switching requests (including
WTR and DNR) are active. NR can also indicates that the highest
local request is overridden by the far end request, whose priority
is higher than the highest local request. Normal traffic signal
is selected from the corresponding transport entity.
van Helvoort, et al. Expires August 17, 2014 [Page 22]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
o LO, SF-P, SD-P: The access by the normal traffic to the protection
transport entity is NOT allowed in this state. The normal traffic
is carried by the working transport entity, regardless of the
fault/degrade condition possibly present (due to the highest
priority of the switching triggers leading to this state).
o FS, SF-W, SD-W, MS-W, MS-P: A switching trigger, NOT resulting in
the protection transport entity unavailability is present. The
normal traffic is selected either from the corresponding working
transport entity or from the protection transport entity,
according to the behavior of the specific switching trigger.
o WTR: In revertive operation, after the clearing of an SF-W or
SD-W, maintains normal traffic as selected from the protection
transport entity until the WTR timer expires or another request
with higher priority, including Clear command, is received. This
is used to prevent frequent operation of the selector in the case
of intermittent failures.
o DNR: In non-revertive operation, this is used to maintain a normal
traffic to be selected from the protection transport entity.
o EXER: Exercise of the APS protocol.
o RR: The near end will enter and signal Reverse Request only in
response to an EXER from the far end.
[State transition tables are shown at the end of the PDF form of this
document.]
10. Security considerations
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
the security model of MPLS. MPLS networks make the assumption that
it is very hard to inject traffic into a network and equally hard to
cause traffic to be directed outside the network. The control-plane
protocols utilize hop-by-hop security and assume a "chain-of-trust"
model such that end-to-end control-plane security is not used. For
more information on the generic aspects of MPLS security, see RFC
5920 [RFC5920].
This document describes a protocol carried in the G-ACh [RFC5586],
and so is dependent on the security of the G-ACh, itself. The G-ACh
is a generalization of the Associated Channel defined in [RFC4385].
Thus, this document relies heavily on the security mechanisms
provided for the Associated Channel and described in those two
documents.
van Helvoort, et al. Expires August 17, 2014 [Page 23]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
11. IANA considerations
There are no IANA actions requested.
12. Acknowledgements
The authors would like to thank Hao Long, Vincenzo Sestito, Italo
Busi, Igor Umansky for their input to and review of the current
document.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
13.2. Informative References
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011.
[I-D.ietf-mpls-psc-updates]
Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
updates-01 (work in progress), January 2014.
[I-D.ietf-mpls-tp-psc-itu]
Ryoo, J., Gray, E., Helvoort, H., D'Alessandro, A.,
Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
TP) Linear Protection to Match the Operational
Expectations of SDH, OTN and Ethernet Transport Network
Operators", draft-ietf-mpls-tp-psc-itu-02 (work in
progress), February 2014.
van Helvoort, et al. Expires August 17, 2014 [Page 24]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
Appendix A. Operation examples of APS protocol
The sequence diagrams shown in this section are only a few examples
of the APS operations. The first APS message which differs from the
previous APS message is shown. The operation of hold-off timer is
omitted. The fields whose values are changed during APS packet
exchange are shown in the APS packet exchange. They are Request/
State, requested traffic, and bridged traffic. For an example,
SF(0,1) represents an APS packet with the following field values:
Request/State = SF, Requested Signal = 0, and Bridged Signal = 1.
The values of the other fields remain unchanged from the initial
configuration. The signal numbers 0 and 1 refer to null signal and
normal traffic signal, respectively. W(A->Z) and P(A->Z) indicate
the working and protection paths in the direction of A to Z,
respectively.
Example 1. 1:1 bidirectional protection switching (revertive mode) -
Unidirectional SF case
A Z
| |
(1) |---- NR(0,0)----->|
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
|<----- NR(1,1)----|
(4) | |
| |
(5) | (Recovery) |
|---- WTR(1,1)---->|
/| |
WTR timer | |
\| |
(6) |---- NR(0,0)----->| (7)
(8) |<----- NR(0,0)----|
| |
(1) The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
(2) Signal Fail occurs on the working entity in the Z to A direction.
Selector and bridge of node A select protection entity. Node A
generates SF(1,1) message.
van Helvoort, et al. Expires August 17, 2014 [Page 25]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
(3) Upon receiving SF(1,1), node Z sets selector and bridge to
protection entity. As there is no local request in node Z, node Z
generates NR(1,1) message.
(4) Node A confirms that the far end is also selecting protection
entity.
(5) Node A detects clearing of SF condition, starts the WTR timer,
and sends WTR(1,1) message.
(6) At expiration of the WTR timer, node A sets selector and bridge
to working entity and sends NR(0,0) message.
(7) Node Z is notified that the far end request has been cleared, and
sets selector and bridge to working entity.
(8) It is confirmed that the far end is also selecting working
entity.
Example 2. 1:1 bidirectional protection switching (revertive mode) -
Bidirectional SF case
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | WTR timer
\| |/
(6) |<---- NR(1,1)---->| (6)
(7) |<----- NR(0,0)--->| (7)
(8) | | (8)
(1) The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
(2) Nodes A and Z detect local Signal Fail conditions on the working
entity, set selector and bridge to protection entity, and generate
SF(1,1) messages.
van Helvoort, et al. Expires August 17, 2014 [Page 26]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
(3) Upon receiving SF(1,1), each node confirms that the far end is
also selecting protection entity.
(4) Each node detects clearing of SF condition, and sends NR(1,1)
message as the last received APS message was SF.
(5) Upon receiving NR(1,1), each node starts the WTR timer and sends
WTR(1,1).
(6) At expiration of the WTR timer, each node sends NR(1,1) as the
last received APS message was WTR.
(7) Upon receiving NR(1,1), each node sets selector and bridge to
working entity and sends NR(0,0) message.
(8) It is confirmed that the far end is also selecting working
entity.
Example 3. 1:1 bidirectional protection switching (revertive mode) -
Bidirectional SF case - Inconsistent WTR timers
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | |
\| | WTR timer
(6) |----- NR(1,1)---->| | (7)
| |/
(9) |<----- NR(0,0)----| (8)
|---- NR(0,0)----->| (10)
(1) The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
(2) Nodes A and Z detect local Signal Fail conditions on the working
entity , set selector and bridge to protection entity, and generate
SF(1,1) messages.
van Helvoort, et al. Expires August 17, 2014 [Page 27]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
(3) Upon receiving SF(1,1), each node confirms that the far end is
also selecting protection entity.
(4) Each node detects clearing of SF condition, and sends NR(1,1)
message as the last received APS message was SF.
(5) Upon receiving NR(1,1), each node starts the WTR timer and sends
WTR(1,1).
(6) At expiration of the WTR timer in node A, node A sends NR(1,1) as
the last received APS message was WTR.
(7) At node Z, the received NR(1,1) is ignored as the local WTR has a
higher priority.
(8) At expiration of the WTR timer in node Z, node Z node sets
selector and bridge to working entity, and sends NR(0,0) message.
(9) Upon receiving NR(0,0), node A sets selector and bridge to
working entity and sends NR(0,0) message.
(10) It is confirmed that the far end is also selecting working
entity.
Example 4. 1:1 bidirectional protection switching (non-revertive
mode) - Unidirectional SF on working followed by unidirectional SF on
protection
van Helvoort, et al. Expires August 17, 2014 [Page 28]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|----- SF(1,1)---->| (3)
(4) |<----- NR(1,1)----|
| |
| |
(5) | (Recovery) |
|----- DNR(1,1)--->| (6)
|<--- DNR(1,1)---->|
| |
| |
| (SF on P(A->Z)) | (7)
(8) |<--- SF-P(0,0)----|
|---- NR(0,0)----->|
| |
| |
| (Recovery) | (9)
|<----- NR(0,0)----|
| |
(1) The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
(2) Signal Fail occurs on the working entity in the Z to A direction.
Selector and bridge of node A select the protection entity. Node A
generates SF(1,1) message.
(3) Upon receiving SF(1,1), node Z sets selector and bridge to
protection entity. As there is no local request in node Z, node Z
generates NR(1,1) message.
(4) Node A confirms that the far end is also selecting protection
entity.
(5) Node A detects clearing of SF condition, and sends DNR(1,1)
message.
(6) Upon receiving DNR(1,1), node Z also generates DNR(1,1) message.
(7) Signal Fail occurs on the protection entity in the A to Z
direction. Selector and bridge of node Z select the working entity.
Node Z generates SF-P(0,0) message.
van Helvoort, et al. Expires August 17, 2014 [Page 29]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
(8) Upon receiving SF-P(0,0), node A sets selector and bridge to
working entity, and generates NR(0,0) message.
(9) Node Z detects clearing of SF condition, and sends NR(0,0)
message.
Exmaple 5. 1:1 bidirectional protection switching (non-revertive
mode) - Bidirectional SF on working followed by bidirectional SF on
protection
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(A<->Z)) | (2)
(3) |<---- SF(1,1)---->| (3)
| |
| |
(4) | (Recovery) | (4)
(5) |<---- NR(1,1)---->| (5)
|<--- DNR(1,1)---->|
| |
| |
(6) | (SF on P(A<->Z)) | (6)
(7) |<--- SF-P(0,0)--->| (7)
| |
| |
(8) | (Recovery) | (8)
|<---- NR(0,0)---->|
| |
(1) The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
(2) Nodes A and Z detect local Signal Fail conditions on the working
entity, set selector and bridge to protection entity, and generate
SF(1,1) messages.
(3) Upon receiving SF(1,1), each node confirms that the far end is
also selecting protection entity.
(4) Each node detects clearing of SF condition, and sends NR(1,1)
message as the last received APS message was SF.
(5) Upon receiving NR(1,1), each node sends DNR(1,1).
van Helvoort, et al. Expires August 17, 2014 [Page 30]
Internet-Draft Pre-standard MPLS-TP Lin. Prot. Switching February 2014
(6) Signal Fail occurs on the protection entity in both directions.
Selector and bridge of each node selects the working entity. Each
node generates SF-P(0,0) message.
(7) Upon receiving SF-P(0,0), each node confirms that the far end is
also selecting working entity
(8) Each node detects clearing of SF condition, and sends NR(0,0)
message.
Authors' Addresses
Huub van Helvoort (editor)
Huawei Technologies
Email: huub.van.helvoort@huawei.com
Jeong-dong Ryoo (editor)
ETRI
Email: ryoo@etri.re.kr
Haiyan Zhang
Huawei Technologies
Email: zhanghaiyan@huawei.com
Feng Huang
Philips
Email: feng.huang@philips.com
Han Li
China Mobile
Email: lihan@chinamobile.com
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
van Helvoort, et al. Expires August 17, 2014 [Page 31]