Internet DRAFT - draft-dong-teas-inter-layer-abstract-error-report
draft-dong-teas-inter-layer-abstract-error-report
Network Working Group J. Dong
Internet-Draft X. Wei
Intended status: Standards Track Huawei Technologies
Expires: January 5, 2016 V. Lopez
O. Gonzalez de Dios
Telefonica I+D
July 4, 2015
RSVP-TE Extensions for Abstract Error Report in Multi-Layer Traffic
Engineered Networks
draft-dong-teas-inter-layer-abstract-error-report-01
Abstract
This document provides extensions to the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to support the report of
abstract error information across the multi-layer network boundary
using Generalized Multiprotocol Label Switching (GMPLS) User Network
Interface (UNI). Such abstract error information is useful for
efficient protection and restoration coordination of multi-layer
Label Switched Paths (LSPs), and is helpful to the fault localization
and diagnostics in the multi-layer networks.
Requirements Language
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].
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 5, 2016.
Dong, et al. Expires January 5, 2016 [Page 1]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
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
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
2. RSVP-TE Extensions for Abstract Error Report . . . . . . . . 4
3. Operation Procedures . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. IF_ID ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . . 7
4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In multi-layer Traffic Engineered (TE) networks, end-to-end Traffic
Engineered (TE) LSPs are established across more than one network
layers. If some failure occurs in the network, according to the type
and location of the failure, different recovery mechanisms could be
used to provide efficient inter-layer protection and restoration for
the end-to-end TE LSPs. Such error information is also helpful for
fault localization, diagnostics and troubleshooting in the multi-
layer networks. However, in multi-layer networks, the exchange of
detailed error information across the layer boundary should be
avoided due to the concerns about confidentiality, scalability and
stability. This document defines RSVP-TE extensions for the abstract
error information report for inter-layer TE LSPs, which can meet the
requirement of efficient protection and fault localization, and the
constraints on information exchange across the multi-layer network
boundaries are not violated .
Dong, et al. Expires January 5, 2016 [Page 2]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
In multi-layer TE networks, several protection mechanisms could be
deployed to protect the end-to-end inter-layer LSPs, such as local
protection in the server layer, end-to-end protection/restoration in
the server layer, and end-to-end protection/restoration initiated in
the client layer. In order to achieve multi-layer protection with
efficient utilization of network resources, appropriate protection
mechanism should be invoked according to the type and location of the
failure.
Client Client
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | |UNI-1| | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN3 +----+ CN4 +---+-----+-+ EN3+- |
| | | | +--+--| | | | | |---+-----+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ |UNI-2| +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN2 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Client Client
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Multi-layer Network Topology
Figure 1 shows a multi-layer network topology which is modified based
on the overlay reference model in [RFC4208] to describe the different
failure and protection scenarios of an inter-layer LSP. Assume in
normal state there is an end-to-end LSP from EN2 to EN3 which
traverses the path: EN2-CN1-CN3-CN4-EN3. There are several failure
cases in which different protection and report behavior should be
performed.
o If a failure occurs in the server layer link CN3-CN4, and the
server layer protection/restoration could recover this by setting
up a new path between CN3 and CN4, then the end-to-end LSP between
EN2 and EN3 will traverse a new path: EN2-CN1-CN3-CN5-CN4-EN3. In
Dong, et al. Expires January 5, 2016 [Page 3]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
this case the client layer protection or restoration is not
needed, while the client layer still SHOULD be informed of the
failure and restoration happened in the server layer for fault
localization and diagnostics, and the characteristics of the new
server layer path may be changed and need to be updated to the
client layer.
o If a failure occurs in the server layer link CN3-CN4, and the
server layer protection/restoration mechanism cannot recover this
failure, then the client layer MUST be informed of this situation
to trigger the client layer protection/restoration mechanism.
o If the UNI interface UNI-1 between the edge node EN3 and the
server layer node CN4 fails, it may be restored efficiently by
using a stand-by UNI interface UNI-2 along with the existing
resources in the server layer. Such restoration may be initiated
either by the ingress edge node of the end-to-end LSP (EN2 in
figure 1), or by the nodes adjacent to the failed UNI link (CN4
and EN3). In both cases the client layer SHOULD be informed of
the failure and recovery happened on the UNI link of the end-to-
end LSP.
o If a failure occurs on the UNI link between EN3 and CN4, and
stand-by UNI interface recovery is not available, the client layer
node EN2 SHOULD be informed of this failure and trigger the client
layer protection/restoration mechanism.
In summary, necessary information about the failure happens in the
end-to-end inter-layer LSPs SHOULD be exchanged between different
network layers for appropriate protection/restoration, fault
localization and diagnostics. The confidentiality concerns in multi-
layer networks SHOULD also be considered.
2. RSVP-TE Extensions for Abstract Error Report
This section specifies the RSVP-TE extensions for abstracted error
information report on the end-to-end inter-layer TE LSPs.
In the IF_ID ERROR_SPEC Object defined in [RFC3473], one new
Interface_ID TLV "ABSTRACT_LOC" is defined to indicate the abstracted
failure location:
Type Length Format Description
-------------------------------------
TBD 4 See below ABSTRACT_LOC
Dong, et al. Expires January 5, 2016 [Page 4]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
The value field of the "ABSTRACT_LOC" TLV is 32 bit flags numbered
from the most significant bit as bit zero. Two flags are defined in
this document:
o Server Layer Internal (I): When set, it indicates the failure
happens inside the server layer.
o UNI (U): When set, it indicates the failure happens on an UNI
interface between the server layer and the client layer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Besides, two new Error Values are defined for Error Code 34 "Reroute"
in [RFC5710] :
o Error Value = TBD1, reroute accomplished
o Error Value = TBD2, upper layer reroute required
3. Operation Procedures
This section describes the procedures of exchanging the abstracted
error report between interconnected server and client network layers.
When a failure occurs in the server layer network, and the server
layer protection/restoration could recover the failure by setting up
a new server layer path, the ingress client layer edge node of the
end-to-end LSP does not need to trigger client layer protection
mechanisms, but it SHOULD be aware of the event happened on the end-
to-end path. The server layer node which recovered the failure MUST
send a PathErr message which carries the ABSTRACT_LOC TLV in the
IF_ID ERROR_SPEC Object, in which the "I" bit is set. The error node
address field MUST be set to zero to indicate this is not to identify
an error of a particular node. The error code SHOULD be "Reroute
(34)" and the Error Value SHOULD be "reroute accomplished". The
upstream server layer nodes SHOULD propagate the received PathErr
message to the previous hop, until the PathErr message reaches the
client layer edge node. Upon receipt of this PathErr message, the
client layer edge node SHOULD not trigger any client layer
protection/restoration mechanism, as it is indicated in the message
that the reroute is accomplished. In this case, the client layer
edge node and the server layer edge node may also exchange the
characteristics of the updated server layer path, details of which is
outside the scope of this document.
Dong, et al. Expires January 5, 2016 [Page 5]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
When a failure occurs in the server layer network, and the server
layer protection/restoration mechanism cannot recover the failure,
the server layer edge node which connects to the ingress client layer
edge node MUST send a PathErr message which carries the ABSTRACT_LOC
TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set. The
error node address field MUST be set to zero to indicate this is not
to identify an error of a particular node. The Error Code SHOULD be
"Reroute (34)" and the Error Value SHOULD be "upper layer reroute
required". Upon receipt of this PathErr message, the ingress client
layer edge node SHOULD trigger the client layer protection/
restoration mechanism to recover the end-to-end LSP.
When the UNI interface which connects the remote server layer edge
and the remote client layer edge fails, and is recovered by a stand-
by UNI interface, the server layer edge node which connects to the
recovered UNI interface MUST send a PathErr message which carries the
ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" bit
is set. The error node address field MUST be set to zero to indicate
this is not to identify an error of a particular node. The Error
Code SHOULD be "Reroute (34)", the Error Value SHOULD be "reroute
accomplished". The upstream server layer nodes SHOULD propagate the
received PathErr message to the previous hop, until the PathErr
message reaches the client layer edge node. Upon receipt of this
PathErr message, the ingress client layer edge node may send a new
Path message to refresh the end-to-end inter-layer LSP.
When a failure happens on the UNI link between the remote server
layer and client layer edge nodes, and the stand-by UNI interface
recovery is not available, the server layer edge node which connects
to the failed UNI interface MUST send a PathErr message which carries
the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U"
bit is set. The error node address field MUST be set to zero to
indicate this is not to identify an error of a particular node. The
Error Code SHOULD be "Reroute (34)" and the Error Value SHOULD be
"upper layer reroute required". The upstream server layer nodes
SHOULD propagate the received PathErr message to the previous hop,
until the PathErr message reaches the client layer edge node. The
client layer edge node SHOULD trigger the client layer protection/
restoration mechanism based on the received PathErr message.
4. IANA Considerations
IANA is requested to administer the assignment of new values defined
in this document and summarized in this section.
Dong, et al. Expires January 5, 2016 [Page 6]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
4.1. IF_ID ERROR_SPEC TLVs
IANA maintains a registry called "GMPLS Signaling Parameters" with a
sub-registry called "Interface_ID Types".
IANA is requested to assign a new TLV type for the "ABSTRACT_LOC" TLV
defined in this document.
4.2. RSVP Error Value Sub-codes
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Error Codes and
Globally-Defined Error Value Sub-Codes".
IANA is requested to assign two new Error Value sub-codes for the
"Reroute" Error Code:
Value | Description | Reference
-----------+--------------------------------+--------------
TBA | reroute accomplished | this document
TBA | upper layer reroute required | this document
5. Security Considerations
This document does not introduce any new security issues above those
identified in [RFC3209] and [RFC3473]. For a more comprehensive
discussion of GMPLS security and attack mitigation techniques, please
see the Security Framework for MPLS and GMPLS Networks [RFC5920].
6. Acknowledgements
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[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.
Dong, et al. Expires January 5, 2016 [Page 7]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr
Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710,
January 2010.
7.2. Informative References
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Xiugang Wei
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: weixiugang@huawei.com
Victor Lopez
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Email: victor.lopezalvarez@telefonica.com
Dong, et al. Expires January 5, 2016 [Page 8]
Internet-Draft GMPLS UNI Abstract Error Report July 2015
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Email: oscar.gonzalezdedios@telefonica.com
Dong, et al. Expires January 5, 2016 [Page 9]
