draft-ietf-mpls-tp-nm-req-00.txt | draft-ietf-mpls-tp-nm-req-01.txt | |||
---|---|---|---|---|
Network Working Group Hing-Kam Lam | Network Working Group Hing-Kam Lam | |||
Internet Draft Alcatel-Lucent | Internet Draft Alcatel-Lucent | |||
Expires: August, 2009 Scott Mansfield | Expires: October, 2009 Scott Mansfield | |||
Intended Status: Informational Eric Gray | Intended Status: Informational Eric Gray | |||
Ericsson | Ericsson | |||
February 23, 2009 | April 15, 2009 | |||
MPLS TP Network Management Requirements | MPLS TP Network Management Requirements | |||
draft-ietf-mpls-tp-nm-req-00.txt | draft-ietf-mpls-tp-nm-req-01.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance | This Internet-Draft is submitted to IETF in full conformance | |||
with the provisions of BCP 78 and BCP 79. | with the provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet | Internet-Drafts are working documents of the Internet | |||
Engineering Task Force (IETF), its areas, and its working | Engineering Task Force (IETF), its areas, and its working | |||
groups. Note that other groups may also distribute working | groups. Note that other groups may also distribute working | |||
documents as Internet-Drafts. | documents as Internet-Drafts. | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
documents at any time. It is inappropriate to use Internet- | documents at any time. It is inappropriate to use Internet- | |||
Drafts as reference material or to cite them other than as "work | Drafts as reference material or to cite them other than as "work | |||
in progress." | in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on August 23, 2009. | This Internet-Draft will expire on October 15, 2009. | |||
Abstract | Abstract | |||
This document specifies the requirements necessary to manage the | This document specifies the requirements necessary to manage the | |||
elements and networks that support an MPLS Transport Profile | elements and networks that support an MPLS Transport Profile | |||
(MPLS-TP). This document is a product of a joint International | (MPLS-TP). This document is a product of a joint International | |||
Telecommunications Union - Telecommunications Standardization | Telecommunications Union - Telecommunications Standardization | |||
Sector (ITU-T) and Internet Engineering Task Force (IETF) effort | Sector (ITU-T) and Internet Engineering Task Force (IETF) effort | |||
to include a MPLS Transport Profile within the IETF MPLS | to include a MPLS Transport Profile within the IETF MPLS | |||
architecture. The requirements are driven by the management | architecture. The requirements are driven by the management | |||
skipping to change at page 2, line 14 | skipping to change at page 2, line 14 | |||
Table of Contents | Table of Contents | |||
1. Introduction................................................3 | 1. Introduction................................................3 | |||
1.1. Terminology............................................3 | 1.1. Terminology............................................3 | |||
2. Management Interface Requirements...........................4 | 2. Management Interface Requirements...........................4 | |||
3. Management Communication Channel (MCC) Requirements.........4 | 3. Management Communication Channel (MCC) Requirements.........4 | |||
4. Management Communication Network (MCN) Requirements.........5 | 4. Management Communication Network (MCN) Requirements.........5 | |||
5. Fault Management Requirements...............................5 | 5. Fault Management Requirements...............................5 | |||
5.1. Supervision Function...................................5 | 5.1. Supervision Function...................................5 | |||
5.2. Validation Function....................................7 | 5.2. Validation Function....................................6 | |||
5.3. Alarm Handling Function................................7 | 5.3. Alarm Handling Function................................7 | |||
5.3.1. Alarm Severity Assignment.........................7 | 5.3.1. Alarm Severity Assignment.........................7 | |||
5.3.2. Alarm Suppression.................................8 | 5.3.2. Alarm Suppression.................................7 | |||
5.3.3. Alarm Reporting Control...........................8 | 5.3.3. Alarm Reporting Control...........................8 | |||
5.3.4. Alarm Reporting...................................8 | 5.3.4. Alarm Reporting...................................8 | |||
6. Configuration Management Requirements.......................9 | 6. Configuration Management Requirements.......................8 | |||
6.1. System Configuration...................................9 | 6.1. System Configuration...................................9 | |||
6.2. Control Plane Configuration............................9 | 6.2. Control Plane Configuration............................9 | |||
6.3. Path Configuration.....................................9 | 6.3. Path Configuration.....................................9 | |||
6.4. Protection Configuration..............................10 | 6.4. Protection Configuration...............................9 | |||
6.5. OAM Configuration.....................................10 | 6.5. OAM Configuration.....................................10 | |||
7. Performance Management Requirements........................11 | 7. Performance Management Requirements........................10 | |||
7.1. Path Characterization Performance Metrics.............11 | 7.1. Path Characterization Performance Metrics.............10 | |||
7.2. Performance Measurement Instrumentation..............12 | 7.2. Performance Measurement Instrumentation..............12 | |||
7.2.1. Measurement Frequency............................12 | 7.2.1. Measurement Frequency............................12 | |||
7.2.2. Measurement Scope................................12 | 7.2.2. Measurement Scope................................12 | |||
8. Security Management Requirements...........................13 | 8. Security Management Requirements...........................13 | |||
8.1. Management Communication Channel Security.............13 | 8.1. Management Communication Channel Security.............13 | |||
8.1.1. Security of Management Communications............13 | 8.2. Signaling Communication Channel Security..............13 | |||
8.2. Signaling Communication Channel Security..............14 | 8.3. Distributed Denial of Service.........................13 | |||
8.3. Data Channel Security.................................14 | ||||
8.4. Distributed Denial of Service.........................14 | ||||
9. Security Considerations....................................14 | 9. Security Considerations....................................14 | |||
10. IANA Considerations.......................................15 | 10. IANA Considerations......................................14 | |||
11. Acknowledgments...........................................15 | 11. Acknowledgments...........................................14 | |||
12. References................................................15 | 12. References................................................14 | |||
12.1. Normative References.................................15 | 12.1. Normative References.................................14 | |||
12.2. Informative References...............................16 | 12.2. Informative References...............................15 | |||
13. Author's Addresses........................................16 | 13. Author's Addresses........................................16 | |||
Copyright Statement...........................................17 | Copyright Statement...........................................16 | |||
Acknowledgment................................................17 | Acknowledgment................................................17 | |||
APPENDIX A: Communication Channel (CC) Examples...............18 | APPENDIX A: Communication Channel (CC) Examples...............18 | |||
1. Introduction | 1. Introduction | |||
This document describes the requirements necessary to manage the | This document describes the requirements necessary to manage the | |||
elements and networks that support an MPLS Transport Profile | elements and networks that support an MPLS Transport Profile | |||
(MPLS-TP). It leverages the management requirements specified | (MPLS-TP). It leverages the management requirements specified | |||
in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 | in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 | |||
[1] specifies generic management requirements for transport | [1] specifies generic management requirements for transport | |||
(including packet-based and circuit-based) networks. RFC 4377 | (including packet-based and circuit-based) networks. RFC 4377 | |||
skipping to change at page 4, line 34 | skipping to change at page 4, line 34 | |||
2. Management Interface Requirements | 2. Management Interface Requirements | |||
This document does not specify which management interface | This document does not specify which management interface | |||
protocol should be the standard protocol for managing MPLS-TP | protocol should be the standard protocol for managing MPLS-TP | |||
networks. Managing an end-to-end connection across multiple | networks. Managing an end-to-end connection across multiple | |||
operator domains where one domain is managed (for example) via | operator domains where one domain is managed (for example) via | |||
NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is | NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is | |||
allowed. | allowed. | |||
For the management interface to the management system, an MPLS- | For the management interface to the management system, an MPLS- | |||
TP NE is not expected to actively support more than one | TP NE MAY actively support more than one management protocol in | |||
management protocol in any given deployment. The protocol to be | any given deployment. For example, an MPLS-TP NE may use one | |||
supported is at the discretion of the operator. | protocol for configuration and another for monitoring. The | |||
protocols to be supported are at the discretion of the operator. | ||||
3. Management Communication Channel (MCC) Requirements | 3. Management Communication Channel (MCC) Requirements | |||
An MPLS-TP management network SHOULD support seamless management | An MPLS-TP management network SHOULD support seamless management | |||
connectivity with remote MPLS-TP domains and NEs as well as with | connectivity with remote MPLS-TP domains and NEs as well as with | |||
termination points located in NEs under control by a third party | termination points located in NEs under control by a third party | |||
network operator. See ITU-T G.8601 [8] for example scenarios in | network operator. See ITU-T G.8601 [8] for example scenarios in | |||
multi-carrier multi-transport-technology environments. | multi-carrier multi-transport-technology environments. | |||
For management purpose, every MPLS-TP NE MUST connect to an OS | For management purpose, every MPLS-TP NE MUST connect to an OS | |||
skipping to change at page 5, line 18 | skipping to change at page 5, line 18 | |||
or more specifically via the MCN. The MCN connects MPLS-TP NEs | or more specifically via the MCN. The MCN connects MPLS-TP NEs | |||
with management systems, NEs with NEs, and management systems | with management systems, NEs with NEs, and management systems | |||
with management systems. Transport DCN architecture and | with management systems. Transport DCN architecture and | |||
requirements are specified in ITU-T G.7712/Y.1703 [7], including | requirements are specified in ITU-T G.7712/Y.1703 [7], including | |||
network layer protocols and their interworking. | network layer protocols and their interworking. | |||
As a practical requirement, MCN connections require addressing. | As a practical requirement, MCN connections require addressing. | |||
See the section on addressing in [13] for further information. | See the section on addressing in [13] for further information. | |||
In order to have the MCN operate properly, a number of | In order to have the MCN operate properly, a number of | |||
management functions for the MCN are required: | management functions for the MCN are required, including: | |||
. Retrieval of DCN network parameters to ensure compatible | . Retrieval of DCN network parameters to ensure compatible | |||
functioning, e.g. packet size, timeouts, quality of | functioning, e.g. packet size, timeouts, quality of | |||
service, window size, etc.; | service, window size, etc.; | |||
. Establishment of message routing between DCN nodes; | . Establishment of message routing between DCN nodes; | |||
. Management of DCN network addresses; | . Management of DCN network addresses; | |||
. Retrieval of operational status of the DCN at a given node; | . Retrieval of operational status of the DCN at a given node; | |||
skipping to change at page 5, line 46 | skipping to change at page 5, line 46 | |||
reporting of abnormal operation of the MPLS-TP network and its | reporting of abnormal operation of the MPLS-TP network and its | |||
environment. | environment. | |||
5.1. Supervision Function | 5.1. Supervision Function | |||
The supervision function analyses the actual occurrence of a | The supervision function analyses the actual occurrence of a | |||
disturbance or fault for the purpose of providing an appropriate | disturbance or fault for the purpose of providing an appropriate | |||
indication of performance and/or detected fault condition to | indication of performance and/or detected fault condition to | |||
maintenance personnel and operations systems. | maintenance personnel and operations systems. | |||
The MPLS-TP NE MUST support supervision of the OAM mechanisms | ||||
that are deployed for supporting the OAM requirements defined in | ||||
[3]. | ||||
The MPLS-TP NE MUST support the following transmission | The MPLS-TP NE MUST support the following transmission | |||
supervision functions: | supervision functions: | |||
. Supervision of continuity check functions used to detect a | ||||
broken connection; | ||||
. Supervision of connectivity check functions used to detect | ||||
misconnection; | ||||
. Supervision of looping check functions used to detect loops | . Supervision of looping check functions used to detect loops | |||
in the data-plane forwarding path (which result in non- | in the data-plane forwarding path (which result in non- | |||
delivery of traffic, wasting of forwarding resources and | delivery of traffic, wasting of forwarding resources and | |||
unintended self-replication of traffic); | unintended self-replication of traffic); | |||
. Supervision of Alarms based on native OAM, e.g., AIS (Alarm | ||||
Indication Signal) and FDI (Forward Defect Indication) | ||||
. Supervision of traffic loss measurement in both directions | ||||
of the bidirectional connection; | ||||
. Supervision of Misinsertion check function used to detect | ||||
misinserted packet in the connection | ||||
. Supervision of Diagnostic test; | ||||
. Supervision of Route determination; | ||||
. Supervision of Remote defect indication; | ||||
. Supervision of the detection of failure in the sequence of | . Supervision of the detection of failure in the sequence of | |||
a protocol exchange (e.g. automatic protection switching | a protocol exchange (e.g. automatic protection switching | |||
protocol); | protocol); | |||
. Supervision of client failure indication. | ||||
The MPLS-TP NE transmission-related supervision mechanisms MUST | The MPLS-TP NE transmission-related supervision mechanisms MUST | |||
support the flexibility to be configured to perform on-demand or | support the flexibility to be configured to perform on-demand or | |||
proactively. | proactively. | |||
The MPLS-TP NE MUST support supervision for software processing | The MPLS-TP NE MUST support supervision for software processing | |||
e.g., processing fault, storage capacity problem, version | e.g., processing fault, storage capacity problem, version | |||
mismatch, Corrupted data, Out of memory, etc. | mismatch, corrupted data, out of memory, etc. | |||
The MPLS-TP NE MUST support hardware-related supervision for | The MPLS-TP NE MUST support hardware-related supervision for | |||
interchangeable and non-interchangeable units, cable, and power | interchangeable and non-interchangeable units, cable, and power | |||
problem. | problem. | |||
The MPLS-TP NE SHOULD support environment-related supervision | The MPLS-TP NE SHOULD support environment-related supervision | |||
for temperature, humidity, etc. | for temperature, humidity, etc. | |||
The MPLS-TP NE MUST support supervision of the OAM mechanisms | ||||
that are deployed for supporting the OAM requirements defined in | ||||
[3]. | ||||
5.2. Validation Function | 5.2. Validation Function | |||
Validation is concerned with the integration of Fault Causes | Validation is concerned with the integration of Fault Causes | |||
into Failures. A Fault Cause indicates a limited interruption of | into Failures. A Fault Cause indicates a limited interruption of | |||
the required transport function. A Fault Cause is not reported | the required transport function. A Fault Cause is not reported | |||
to maintenance personnel because it could exist only for a very | to maintenance personnel because it could exist only for a very | |||
short time. Note that some of these events however are summed up | short time. Note that some of these events however are summed up | |||
in the Performance Monitoring process, and when this sum exceeds | in the Performance Monitoring process, and when this sum exceeds | |||
a certain value, a Threshold Report can be generated. | a certain value, a Threshold Report can be generated. | |||
skipping to change at page 8, line 18 | skipping to change at page 7, line 44 | |||
See G.7710 [1] for more description about alarm severity | See G.7710 [1] for more description about alarm severity | |||
assignment. | assignment. | |||
5.3.2. Alarm Suppression | 5.3.2. Alarm Suppression | |||
Alarms may be generated from many sources, including OAM, device | Alarms may be generated from many sources, including OAM, device | |||
status, etc. | status, etc. | |||
An MPLS-TP NE MUST provide alarm suppression functionality that | An MPLS-TP NE MUST provide alarm suppression functionality that | |||
prevents the generation of a superfluous alarms. | prevents the generation of superfluous alarms. | |||
Examples of alarm suppression mechanisms include simply | Examples of alarm suppression mechanisms include simply | |||
discarding the alarms (or not generating them in the first | discarding the alarms (or not generating them in the first | |||
place), or aggregating the alarms together, thereby greatly | place), or aggregating the alarms together, thereby greatly | |||
reducing the number of alarm notifications to be emitted. | reducing the number of alarm notifications to be emitted. | |||
Note: An MPLS-TP NE supporting the inter-working of one or more | Note: An MPLS-TP NE supporting the inter-working of one or more | |||
networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with | networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with | |||
MPLS-TP needs to translate an MPLS-TP fault into an existing | MPLS-TP needs to translate an MPLS-TP fault into an existing | |||
transport technology failure condition for reporting to the | transport technology failure condition for reporting to the | |||
skipping to change at page 9, line 12 | skipping to change at page 8, line 40 | |||
events and conditions, which occur in the network (including the | events and conditions, which occur in the network (including the | |||
NE, incoming signal, and external environment). | NE, incoming signal, and external environment). | |||
Local reporting is concerned with automatic alarming by means of | Local reporting is concerned with automatic alarming by means of | |||
audible and visual indicators near the failed equipment. | audible and visual indicators near the failed equipment. | |||
An MPLS-TP NE MUST support local reporting of alarms. | An MPLS-TP NE MUST support local reporting of alarms. | |||
The MPLS-TP NE MUST support reporting of alarms to an OS. These | The MPLS-TP NE MUST support reporting of alarms to an OS. These | |||
reports are either autonomous reports (notifications) or reports | reports are either autonomous reports (notifications) or reports | |||
on request by maintenance personnel. The MPLS-TP ME SHOULD | on request by maintenance personnel. The MPLS-TP NE SHOULD | |||
report local (environmental) alarms to a network management | report local (environmental) alarms to a network management | |||
system. | system. | |||
6. Configuration Management Requirements | 6. Configuration Management Requirements | |||
Configuration Management provides functions to identify, collect | Configuration Management provides functions to identify, collect | |||
data from, provide data to and control NEs. Specific | data from, provide data to and control NEs. Specific | |||
configuration tasks requiring network management support include | configuration tasks requiring network management support include | |||
hardware and software configuration, configuration of NEs to | hardware and software configuration, configuration of NEs to | |||
support transport paths (including required working and | support transport paths (including required working and | |||
skipping to change at page 10, line 30 | skipping to change at page 10, line 14 | |||
6.5. OAM Configuration | 6.5. OAM Configuration | |||
The MPLS-TP NE MUST provide the capability to configure the OAM | The MPLS-TP NE MUST provide the capability to configure the OAM | |||
entities and functions specified in [3]. | entities and functions specified in [3]. | |||
The MPLS-TP NE MUST support the capability to choose which OAM | The MPLS-TP NE MUST support the capability to choose which OAM | |||
functions to use and which maintenance entity to apply them. | functions to use and which maintenance entity to apply them. | |||
The MPLS-TP NE MUST support the capability to configure the OAM | The MPLS-TP NE MUST support the capability to configure the OAM | |||
entities/functions as part of LSP setup, including bidirectional | entities/functions as part of LSP setup and tear-down, including | |||
point-to-point connections, associated uni-directional point-to- | co-routed bidirectional point-to-point, associated bidirectional | |||
point connections, and uni-directional point-to-multipoint | point-to-point, and uni-directional (both point-to-point and | |||
connections. | point-to-multipoint) connections. | |||
The MPLS-TP NE MUST support the configuration of maintenance | The MPLS-TP NE MUST support the configuration of maintenance | |||
entity identifiers (e.g. MEP ID and MIP ID) for the purpose of | entity identifiers (e.g. MEP ID and MIP ID) for the purpose of | |||
LSP connectivity checking. | LSP connectivity checking. | |||
The MPLS-TP NE MUST have the flexibility to configure OAM | The MPLS-TP NE MUST have the flexibility to configure OAM | |||
parameters to meet their specific operational requirements, such | parameters to meet their specific operational requirements, such | |||
as whether (1) one-time on-demand immediately or (2) one-time | as whether (1) one-time on-demand immediately or (2) one-time | |||
on-demand pre-scheduled or (3) on-demand periodically based on a | on-demand pre-scheduled or (3) on-demand periodically based on a | |||
specified schedule or (4) proactive on-going. | specified schedule or (4) proactive on-going. | |||
skipping to change at page 12, line 44 | skipping to change at page 12, line 24 | |||
7.2.1. Measurement Frequency | 7.2.1. Measurement Frequency | |||
The performance measurement mechanisms MUST support the | The performance measurement mechanisms MUST support the | |||
flexibility to be configured to operate on-demand or proactively | flexibility to be configured to operate on-demand or proactively | |||
(i.e. continuously over a period of time). | (i.e. continuously over a period of time). | |||
7.2.2. Measurement Scope | 7.2.2. Measurement Scope | |||
On measurement of packet loss and loss ratio: | On measurement of packet loss and loss ratio: | |||
- For bidirectional P2P connections - | - For bidirectional (both co-routed and associated) P2P | |||
connections - | ||||
. on-demand measurement of single-ended packet loss, | ||||
and loss ratio, measurement are required; | ||||
. proactive measurement of packet loss, and loss | ||||
ratio, measurement for each direction are required. | ||||
- For associated unidirectional P2P connections - | ||||
. on-demand measurement of single-ended packet loss, | . on-demand measurement of single-ended packet loss, | |||
and loss ratio, measurement are required; | and loss ratio, measurement are required; | |||
. proactive measurement of packet loss, and loss | . proactive measurement of packet loss, and loss | |||
ratio, measurement for each direction are required. | ratio, measurement for each direction are required. | |||
Note: for associated unidirectional P2P connections, this data | Note: for associated bidirectional P2P connections, this data | |||
can only be measured at end-points. | can only be measured at end-points. | |||
- For unidirectional (P2P and P2MP) connection, proactive | - For unidirectional (P2P and P2MP) connection, proactive | |||
measurement of packet loss, and loss ratio, are required. | measurement of packet loss, and loss ratio, are required. | |||
On Delay measurement: | On Delay measurement: | |||
- For unidirectional (P2P and P2MP) connection, on-demand | - For unidirectional (P2P and P2MP) connection, on-demand | |||
measurement of delay measurement is required. | measurement of delay measurement is required. | |||
- For bidirectional (P2P) connection, on-demand measurement | - For co-routed bidirectional (P2P) connection, on-demand | |||
of one-way and two-way delay are required. | measurement of one-way and two-way delay are required. | |||
- For associated bidirectional (P2P) connection, on-demand | ||||
measurement of one-way delay is required. | ||||
8. Security Management Requirements | 8. Security Management Requirements | |||
The MPLS-TP NE MUST support secure management and control | The MPLS-TP NE MUST support secure management and control | |||
planes. | planes. | |||
8.1. Management Communication Channel Security | 8.1. Management Communication Channel Security | |||
Secure channels MUST be provided for all network traffic and | Secure channels MUST be provided for all network traffic and | |||
protocols used to support management functions. This MUST | protocols used to support management functions. This MUST | |||
include, at least, protocols used for configuration, monitoring, | include, at least, protocols used for configuration, monitoring, | |||
configuration backup, logging, time synchronization, | configuration backup, logging, time synchronization, | |||
authentication, and routing. The MCC MUST support application | authentication, and routing. The MCC MUST support application | |||
protocols that provide confidentiality and data integrity | protocols that provide confidentiality and data integrity | |||
protection. | protection. | |||
8.1.1. Security of Management Communications | ||||
If management communication security is provided, the MPLS-TP NE | If management communication security is provided, the MPLS-TP NE | |||
MUST support the following: | MUST support the following: | |||
- Use of open cryptographic algorithms (See RFC 3871 [5]) | - Use of open cryptographic algorithms (See RFC 3871 [5]) | |||
- Authentication - allow management connectivity only from | - Authentication - allow management connectivity only from | |||
authenticated entities. | authenticated entities. | |||
- Authorization - allow management activity originated by an | - Authorization - allow management activity originated by an | |||
authorized entity, using (for example) an Access Control | authorized entity, using (for example) an Access Control | |||
skipping to change at page 14, line 21 | skipping to change at page 13, line 44 | |||
8.2.Signaling Communication Channel Security | 8.2.Signaling Communication Channel Security | |||
Security considerations for the SCC are similar to the | Security considerations for the SCC are similar to the | |||
considerations driving the requirements described in section | considerations driving the requirements described in section | |||
8.1. Security Requirements for the control plane are out of | 8.1. Security Requirements for the control plane are out of | |||
scope for this document and are expected to be defined in the | scope for this document and are expected to be defined in the | |||
appropriate control plane specifications. Management of the | appropriate control plane specifications. Management of the | |||
control plane security must also be defined at that time. | control plane security must also be defined at that time. | |||
8.3. Data Channel Security | 8.3. Distributed Denial of Service | |||
8.4.Distributed Denial of Service | ||||
Denial of Service (DoS) attack is an attack which tries to | Denial of Service (DoS) attack is an attack which tries to | |||
prevent a target from performing an assigned task, or providing | prevent a target from performing an assigned task, or providing | |||
its intended service(s), through any means. A Distributed DoS | its intended service(s), through any means. A Distributed DoS | |||
(DDoS) can multiply attack severity (possibly by an arbitrary | (DDoS) can multiply attack severity (possibly by an arbitrary | |||
amount) by using multiple (potentially compromised) systems to | amount) by using multiple (potentially compromised) systems to | |||
act as topologically (and potentially geographically) | act as topologically (and potentially geographically) | |||
distributed attack sources. It is possible to lessen the impact | distributed attack sources. It is possible to lessen the impact | |||
and potential for DDOS by using secure protocols, turning off | and potential for DDOS by using secure protocols, turning off | |||
unnecessary processes, logging and monitoring, and ingress | unnecessary processes, logging and monitoring, and ingress | |||
filtering. RFC 4732 [4] provides background on DOS in the | filtering. RFC 4732 [4] provides background on DOS in the | |||
context of the Internet. | context of the Internet. | |||
9. Security Considerations | 9. Security Considerations | |||
Section 8 lists a set of security requirements that apply to | Section 8 includes a set of security requirements that apply to | |||
MPLS-TP network management. | MPLS-TP network management. | |||
Provisions to any of the network mechanisms designed to satisfy | Solutions MUST provide mechanisms to prevent unauthorized and/or | |||
the requirements described herein are required to prevent their | unauthenticated access to private information by network | |||
unauthorized use. Likewise, these network mechanisms MUST | elements, systems or users. | |||
provide a means by which an operator can prevent denial of | ||||
service attacks if those network mechanisms are used in such an | ||||
attack. | ||||
Solutions MUST provide mechanisms to prevent this private | ||||
information from being accessed by unauthorized eavesdropping, | ||||
or being directly obtained by an unauthenticated network | ||||
element, system or user. | ||||
Performance of diagnostic functions and path characterization | Performance of diagnostic functions and path characterization | |||
involves extracting a significant amount of information about | involves extracting a significant amount of information about | |||
network construction that the network operator MAY consider | network construction that the network operator MAY consider | |||
private. | private. | |||
10. IANA Considerations | 10. IANA Considerations | |||
<insert IANA considerations, if any, here) | There are no IANA actions associated with this document. | |||
11. Acknowledgments | 11. Acknowledgments | |||
The authors/editors gratefully acknowledge the thoughtful | The authors/editors gratefully acknowledge the thoughtful | |||
review, comments and explanations provided by Adrian Farrel, | review, comments and explanations provided by Adrian Farrel, | |||
Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego | Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego | |||
Caviglia, Dieter Beller, He Jia, Leo Xiao and Maarten Vissers. | Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil | |||
Harrison and Rolf Winter. | ||||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment | [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment | |||
management function requirements", July, 2007. | management function requirements", July, 2007. | |||
[2] Nadeau, T., et al., "Operations and Management (OAM) | [2] Nadeau, T., et al, "Operations and Management (OAM) | |||
Requirements for Multi-Protocol Label Switched (MPLS) | Requirements for Multi-Protocol Label Switched (MPLS) | |||
Networks", RFC 4377, February 2006. | Networks", RFC 4377, February 2006. | |||
[3] Vigoureus, M., et al., "Requirements for OAM in MPLS | [3] Vigoureus, M., et al, "Requirements for OAM in MPLS | |||
Transport Networks", work in progress. | Transport Networks", work in progress. | |||
[4] Handley, M., et al., "Internet Denial-of-Service | [4] Handley, M., et al, "Internet Denial-of-Service | |||
Considerations", RFC 4732, November 2006. | Considerations", RFC 4732, November 2006. | |||
[5] Jones, G., "Operational Security Requirements for Large | [5] Jones, G., "Operational Security Requirements for Large | |||
Internet Service Provider (ISP) IP Network | Internet Service Provider (ISP) IP Network | |||
Infrastructure", RFC 3871, September 2004. | Infrastructure", RFC 3871, September 2004. | |||
[6] Bradner, S., "Key words for use in RFCs to Indicate | [6] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, March 1997. | Requirement Levels", RFC 2119, March 1997. | |||
[7] ITU-T Recommendation G.7712/Y.1703, "Architecture and | [7] ITU-T Recommendation G.7712/Y.1703, "Architecture and | |||
Specification of Data Communication Network", June 2008. | Specification of Data Communication Network", June 2008. | |||
[8] ITU-T Recommendation G.8601, "Architecture of service | [8] ITU-T Recommendation G.8601, "Architecture of service | |||
management in multi bearer, multi carrier environment", | management in multi bearer, multi carrier environment", | |||
June 2006. | June 2006. | |||
[9] Lam, H., et al., "Alarm Reporting Control Management | [9] Lam, H., et al, "Alarm Reporting Control Management | |||
Information Base (MIB)", RFC 3878, September 2004. | Information Base (MIB)", RFC 3878, September 2004. | |||
12.2. Informative References | 12.2. Informative References | |||
[10] Chisholm, S. and D. Romascanu, "Alarm Management | [10] Chisholm, S. and D. Romascanu, "Alarm Management | |||
Information Base (MIB)", RFC 3877, September 2004. | Information Base (MIB)", RFC 3877, September 2004. | |||
[11] ITU-T Recommendation M.20, "Maintenance Philosophy for | [11] ITU-T Recommendation M.20, "Maintenance Philosophy for | |||
Telecommunication Networks", October 1992. | Telecommunication Networks", October 1992. | |||
[12] Telcordia, "Network Maintenance: Network Element and | [12] Telcordia, "Network Maintenance: Network Element and | |||
Transport Surveillance Messages" (GR-833-CORE), Issue 5, | Transport Surveillance Messages" (GR-833-CORE), Issue 5, | |||
August 2004. | August 2004. | |||
[13] Bocci, M. et al., "A Framework for MPLS in Transport | [13] Bocci, M. et al, "A Framework for MPLS in Transport | |||
Networks", Work in Progress, November 27, 2008. | Networks", Work in Progress, November 27, 2008. | |||
[14] ANSI T1.231-2003, "Layer 1 In-Service Transmission | [14] ANSI T1.231-2003, "Layer 1 In-Service Transmission | |||
Performance Monitoring", American National Standards | Performance Monitoring", American National Standards | |||
Institute, 2003. | Institute, 2003. | |||
[15] Vigoureux, M. et al, "MPLS Generic Associated Channel", | ||||
draft-ietf-mpls-tp-gach-gal, work in progress. | ||||
13. Author's Addresses | 13. Author's Addresses | |||
Editors: | Editors: | |||
Scott Mansfield | Scott Mansfield | |||
Ericsson | Ericsson | |||
5000 Ericsson Drive | 5000 Ericsson Drive | |||
Warrendale, PA, 15086 | Warrendale, PA, 15086 | |||
Phone: +1 724 742 6726 | Phone: +1 724 742 6726 | |||
EMail: Scott.Mansfield@Ericsson.com | EMail: Scott.Mansfield@Ericsson.com | |||
skipping to change at page 17, line 12 | skipping to change at page 16, line 34 | |||
Ericsson | Ericsson | |||
900 Chelmsford Street | 900 Chelmsford Street | |||
Lowell, MA, 01851 | Lowell, MA, 01851 | |||
Phone: +1 978 275 7470 | Phone: +1 978 275 7470 | |||
Email: Eric.Gray@Ericsson.com | Email: Eric.Gray@Ericsson.com | |||
Author(s): | Author(s): | |||
Contributor(s): | Contributor(s): | |||
Adrian Farrel | ||||
Old Dog Consulting | ||||
Email: adrian@olddog.co.uk | ||||
Copyright Statement | Copyright Statement | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 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 in effect on the date of | |||
(http://trustee.ietf.org/license-info) in effect on the date of | publication of this document (http://trustee.ietf.org/license- | |||
publication of this document. Please review these documents | info). Please review these documents carefully, as they | |||
carefully, as they describe your rights and restrictions with | describe your rights and restrictions with respect to this | |||
respect to this document. | document. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
APPENDIX A: Communication Channel (CC) Examples | APPENDIX A: Communication Channel (CC) Examples | |||
A CC may be realized in a number of ways. | A CC may be realized in a number of ways. | |||
skipping to change at page 18, line 50 | skipping to change at page 18, line 50 | |||
bytes does not reduce the capacity of the associated data | bytes does not reduce the capacity of the associated data | |||
channel. | channel. | |||
This is an "overhead-based CC". | This is an "overhead-based CC". | |||
This alternative is not available in MPLS-TP because there is no | This alternative is not available in MPLS-TP because there is no | |||
overhead available. | overhead available. | |||
5. The CC may provided by a dedicated channel associated with | 5. The CC may provided by a dedicated channel associated with | |||
the data link. For example, the generic associated label (GAL) | the data link. For example, the generic associated label (GAL) | |||
[GAL-GACH] may be used to label DCC traffic being exchanged on a | [15] may be used to label DCC traffic being exchanged on a data | |||
data link between adjacent transport nodes, potentially in the | link between adjacent transport nodes, potentially in the | |||
absence of any data LSP between those nodes. | absence of any data LSP between those nodes. | |||
This is a "data link associated CC". | This is a "data link associated CC". | |||
It is very similar to case 2, and by its nature can only span a | It is very similar to case 2, and by its nature can only span a | |||
single hop in the transport network. | single hop in the transport network. | |||
6. The CC may be provided by a dedicated channel associated with | 6. The CC may be provided by a dedicated channel associated with | |||
a data channel. For example, in MPLS-TP the GAL [GAL-GACH] may | a data channel. For example, in MPLS-TP the GAL [15] may be | |||
be imposed under the top label in the label stack for an MPLS-TP | imposed under the top label in the label stack for an MPLS-TP | |||
LSP to create a channel associated with the LSP that may carry | LSP to create a channel associated with the LSP that may carry | |||
management traffic. This CC requires the receiver to be capable | management traffic. This CC requires the receiver to be capable | |||
of demultiplexing management traffic from user traffic carried | of demultiplexing management traffic from user traffic carried | |||
on the same LSP by use of the GAL. | on the same LSP by use of the GAL. | |||
This is a "data channel associated CC". | This is a "data channel associated CC". | |||
7. The CC may be provided by mixing the management traffic with | 7. The CC may be provided by mixing the management traffic with | |||
the user traffic such that is indistinguishable on the link | the user traffic such that is indistinguishable on the link | |||
without deep-packet inspection. In MPLS-TP this could arise if | without deep-packet inspection. In MPLS-TP this could arise if | |||
End of changes. 42 change blocks. | ||||
102 lines changed or deleted | 71 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |