rfc4394.original | rfc4394.txt | |||
---|---|---|---|---|
Network Working Group Don Fedyk (Nortel Networks) | Network Working Group D. Fedyk | |||
Internet Draft Osama Aboul-Magd (Nortel Networks) | Request for Comments: 4394 O. Aboul-Magd | |||
Category: Informational Deborah Brungard (AT&T) | Category: Informational Nortel Networks | |||
Expires October 2005 Jonathan Lang (Sonos, Inc.) | D. Brungard | |||
Dimitri Papadimitriou (Alcatel) | AT&T | |||
J. Lang | ||||
May 2005 | Sonos, Inc. | |||
D. Papadimitriou | ||||
A Transport Network View of the Link Management Protocol | Alcatel | |||
<draft-ietf-ccamp-transport-lmp-02.txt> | February 2006 | |||
Status of this Memo | A Transport Network View of the Link Management Protocol (LMP) | |||
By submitting this Internet-Draft, each author represents that any | Status of This Memo | |||
applicable patent or other IPR claims of which he or she is aware | ||||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This memo provides information for the Internet community. It does | |||
Task Force (IETF), its areas, and its working groups. Note that | not specify an Internet standard of any kind. Distribution of this | |||
other groups may also distribute working documents as Internet- | memo is unlimited. | |||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Copyright Notice | |||
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." | ||||
The list of current Internet-Drafts can be accessed at | Copyright (C) The Internet Society (2006). | |||
http://www.ietf.org/ietf/1id-abstracts.txt | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
Abstract | Abstract | |||
The Link Management Protocol (LMP) has been developed as part of the | The Link Management Protocol (LMP) has been developed as part of the | |||
Generalized MPLS (GMPLS) protocol suite to manage Traffic | Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering | |||
Engineering (TE) resources and links. The GMPLS control plane | (TE) resources and links. The GMPLS control plane (routing and | |||
(routing and signaling) uses TE links for establishing Label | signaling) uses TE links for establishing Label Switched Paths | |||
Switched Paths (LSPs). This memo describes the relationship of the | (LSPs). This memo describes the relationship of the LMP procedures | |||
LMP procedures to 'discovery' as defined in the International | to 'discovery' as defined in the International Telecommunication | |||
Telecommunication Union (ITU-T), and on-going ITU-T work. This | Union (ITU-T), and ongoing ITU-T work. This document provides an | |||
document provides an overview of LMP in the context of the ITU-T | overview of LMP in the context of the ITU-T Automatically Switched | |||
Automatically Switched Optical Networks (ASON) and transport network | Optical Networks (ASON) and transport network terminology and relates | |||
terminology and relates it to the ITU-T discovery work to promote a | it to the ITU-T discovery work to promote a common understanding for | |||
common understanding for progressing the work of IETF and ITU-T. | progressing the work of IETF and ITU-T. | |||
D. Fedyk, Editor Informational 1 | ||||
Table of Contents | Table of Contents | |||
1. ASON Terminology and Abbreviations related to Discovery.........2 | 1. Introduction ....................................................2 | |||
1.1 Terminology....................................................2 | 2. ASON Terminology and Abbreviations Related to Discovery .........3 | |||
1.2 Abbreviations.................................................3 | 2.1. Terminology ................................................3 | |||
2. Introduction....................................................3 | 2.2. Abbreviations ..............................................4 | |||
3. Transport Network Architecture..................................4 | 3. Transport Network Architecture ..................................5 | |||
3.1 G.8080 Discovery Framework.....................................6 | 3.1. G.8080 Discovery Framework .................................7 | |||
4. Discovery Technologies..........................................8 | 4. Discovery Technologies ..........................................9 | |||
4.1 Generalized automatic discovery techniques G.7714..............8 | 4.1. Generalized Automatic Discovery Techniques G.7714 ..........9 | |||
4.2 LMP and G.8080 Terminology Mapping.............................9 | 4.2. LMP and G.8080 Terminology Mapping .........................9 | |||
4.2.1 TE Link Definition and Scope................................10 | 4.2.1. TE Link Definition and Scope .......................12 | |||
4.3 LMP and G.8080 Discovery Relationship.........................12 | 4.3. LMP and G.8080 Discovery Relationship .....................13 | |||
4.4 Comparing LMP and G.8080......................................13 | 4.4. Comparing LMP and G.8080 ..................................14 | |||
5. Security Considerations........................................13 | 5. Security Considerations ........................................15 | |||
6. IANA Considerations............................................14 | 6. Informative References .........................................15 | |||
7. Intellectual Property Considerations...........................14 | 7. Acknowledgements ...............................................16 | |||
8. References.....................................................15 | ||||
8.1 Normative References..........................................15 | ||||
8.2 Informational References......................................15 | ||||
9. Acknowledgements...............................................16 | ||||
10. Author's Addresses............................................16 | ||||
11. Disclaimer of Validity........................................17 | ||||
12. Full Copyright Statement......................................17 | ||||
1. ASON Terminology and Abbreviations related to Discovery | 1. Introduction | |||
1.1 Terminology | The GMPLS control plane consists of several building blocks as | |||
described in [RFC3945]. The building blocks include signaling, | ||||
routing, and link management for establishing LSPs. For scalability | ||||
purposes, multiple physical resources can be combined to form a | ||||
single TE link for the purposes of path computation and GMPLS control | ||||
plane signaling. | ||||
As manual provisioning and management of these links are impractical | ||||
in large networks, LMP was specified to manage TE links. Two | ||||
mandatory management capabilities of LMP are control channel | ||||
management and TE link property correlation. Additional optional | ||||
capabilities include verifying physical connectivity and fault | ||||
management. [LMP] defines the messages and procedures for GMPLS TE | ||||
link management. [LMP-TEST] defines SONET/SDH-specific messages and | ||||
procedures for link verification. | ||||
ITU-T Recommendation G.8080 Amendment 1 [G.8080] defines control | ||||
plane discovery as two separate processes; one process occurs within | ||||
the transport plane space and the other process occurs within the | ||||
control plane space. | ||||
The ITU-T has developed Recommendation G.7714, "Generalized automatic | ||||
discovery techniques" [G.7714], defining the functional processes and | ||||
information exchange related to transport plane discovery aspects, | ||||
i.e., layer adjacency discovery and physical media adjacency | ||||
discovery. Specific methods and protocols are not defined in | ||||
Recommendation G.7714. ITU-T Recommendation G.7714.1, "Protocol for | ||||
automatic discovery in SDH and OTN networks" [G.7714.1], defines a | ||||
protocol and procedure for transport plane layer adjacency discovery | ||||
(e.g., discovering the transport plane layer endpoint relationships | ||||
and verifying their connectivity). The ITU-T is currently working to | ||||
extend discovery to control plane aspects providing detail on a | ||||
discovery framework architecture in G.8080 and a new Recommendation | ||||
on "Control plane initial establishment, reconfiguration". | ||||
2. ASON Terminology and Abbreviations Related to Discovery | ||||
ITU-T Recommendation G.8080 Amendment 1 [G.8080] and ITU-T | ||||
Recommendation G.7714 [G.7714] provide definitions and mechanisms | ||||
related to transport plane discovery. | ||||
Note that in the context of this work, "Transport" relates to the | ||||
data plane (sometimes called the transport plane or the user plane) | ||||
and does not refer to the transport layer (layer 4) of the OSI seven | ||||
layer model, nor to the concept of transport intended by protocols | ||||
such as the Transmission Control Protocol (TCP). | ||||
Special care must be taken with the acronym "TCP", which within the | ||||
context of the rest of this document means "Termination Connection | ||||
Point" and does not indicate the Transmission Control Protocol. | ||||
2.1. Terminology | ||||
The reader is assumed to be familiar with the terminology in [LMP] | The reader is assumed to be familiar with the terminology in [LMP] | |||
and [LMP-TEST]. The following ITU-T terminology/abbreviations are | and [LMP-TEST]. The following ITU-T terminology/abbreviations are | |||
used in this document: | used in this document: | |||
Connection Point (CP): A "reference point" that consists of a pair | Connection Point (CP): A "reference point" that consists of a pair of | |||
of co-located "unidirectional connection points" and therefore | co-located "unidirectional connection points" and therefore | |||
represents the binding of two paired bidirectional "connections". | represents the binding of two paired bidirectional "connections". | |||
Connection Termination Point (CTP): A Connection Termination Point | Connection Termination Point (CTP): A connection termination point | |||
(CTP) represents the state of a CP [M.3100]. | represents the state of a CP [M.3100]. | |||
Characteristic Information: Signal with a specific format, which is | Characteristic Information: Signal with a specific format, which is | |||
transferred on "network connections". The specific formats will be | transferred on "network connections". The specific formats will be | |||
defined in the technology specific Recommendations. For trails the | defined in the technology-specific recommendations. For trails, the | |||
Characteristic Information is the payload plus the overhead. The | Characteristic Information is the payload plus the overhead. The | |||
information transferred is characteristic of the layer network. | information transferred is characteristic of the layer network. | |||
Link: a subset of ports at the edge of a subnetwork or access group | Link: A subset of ports at the edge of a subnetwork or access group | |||
which are associated with a corresponding subset of ports at the | that are associated with a corresponding subset of ports at the edge | |||
edge of another subnetwork or access group. | of another subnetwork or access group. | |||
Link Connection (LC): a transport entity that transfers information | Link Connection (LC): A transport entity that transfers information | |||
between ports across a link. | between ports across a link. | |||
D. Fedyk, Editor Informational 2 | ||||
Network Connection (NC): A concatenation of link and subnetwork | Network Connection (NC): A concatenation of link and subnetwork | |||
connections. | connections. | |||
Subnetwork: a set of ports which are available for the purpose of | Subnetwork: A set of ports that are available for the purpose of | |||
routing 'characteristic information'. | routing 'characteristic information'. | |||
Subnetwork Connection (SNC): a flexible connection that is setup and | Subnetwork Connection (SNC): A flexible connection that is set up and | |||
released using management or control plane procedures. | released using management or control plane procedures. | |||
Subnetwork Point (SNP): SNP is an abstraction that represents an | Subnetwork Point (SNP): SNP is an abstraction that represents an | |||
actual or potential underlying connection point (CP) or termination | actual or potential underlying connection point (CP) or termination | |||
connection point (TCP) for the purpose of control plane | connection point (TCP) for the purpose of control plane | |||
representation. | representation. | |||
Subnetwork Point Pool (SNPP): A set of SNP that are grouped together | Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together | |||
for the purpose of routing. | for the purpose of routing. | |||
Termination Connection Point (TCP): A reference point that | Termination Connection Point (TCP): A reference point that represents | |||
represents the output of a Trail Termination source function or the | the output of a Trail Termination source function or the input to a | |||
input to a Trail Termination sink function. A network connection | Trail Termination sink function. A network connection represents a | |||
represents a transport entity between TCPs. | transport entity between TCPs. | |||
Trail Termination source/sink function: A "transport processing | Trail Termination source/sink function: A "transport processing | |||
function" which accepts the characteristic information of the layer | function" that accepts the characteristic information of the layer | |||
network at its input, removes the information related to "trail" | network at its input, removes the information related to "trail" | |||
monitoring and presents the remaining information at its output. | monitoring, and presents the remaining information at its output. | |||
Unidirectional Connection: A "transport entity" which transfers | ||||
Unidirectional Connection: A "transport entity" that transfers | ||||
information transparently from input to output. | information transparently from input to output. | |||
Unidirectional Connection Point: A "reference point" that represents | Unidirectional Connection Point: A "reference point" that represents | |||
the binding of the output of a "unidirectional connection" to the | the binding of the output of a "unidirectional connection" to the | |||
input of another "unidirectional connection". | input of another "unidirectional connection". | |||
1.2 Abbreviations | 2.2. Abbreviations | |||
LMP: Link Management Protocol | LMP: Link Management Protocol | |||
OTN: Optical transport network | OTN: Optical Transport Network | |||
PDH: Plesiosynchronous digital hierarchy | ||||
SDH: Synchronous digital hierarchy. | ||||
2. Introduction | ||||
The GMPLS control plane consists of several building blocks as | ||||
described in [RFC3945]. The building blocks include signaling, | ||||
routing, and link management for establishing LSPs. For scalability | ||||
purposes, multiple physical resources can be combined to form a | ||||
single traffic engineering (TE) link for the purposes of path | ||||
computation and GMPLS control plane signaling. | ||||
D. Fedyk, Editor Informational 3 | PDH: Plesiosynchronous Digital Hierarchy | |||
As manual provisioning and management of these links is impractical | ||||
in large networks, LMP was specified to manage TE links. Two | ||||
mandatory management capabilities of LMP are control channel | ||||
management and TE link property correlation. Additional optional | ||||
capabilities include verifying physical connectivity and fault | ||||
management. [LMP] defines the messages and procedures for GMPLS TE | ||||
link management. [LMP-TEST] defines SONET/SDH specific messages and | ||||
procedures for link verification. | ||||
ITU-T Recommendation G.8080 Amendment 1 [G.8080] defines control | SDH: Synchronous Digital Hierarchy | |||
plane discovery as two separate processes, one process occurs within | ||||
the transport plane space and the other process occurs within the | ||||
control plane space. | ||||
The ITU-T has developed Recommendation G.7714 'Generalized automatic | SONET: Synchronous Optical Network | |||
discovery techniques' [G.7714] defining the functional processes and | ||||
information exchange related to transport plane discovery aspects: | ||||
i.e., layer adjacency discovery and physical media adjacency | ||||
discovery. Specific methods and protocols are not defined in | ||||
Recommendation G.7714. ITU-T Recommendation G.7714.1 'Protocol for | ||||
automatic discovery in SDH and OTN networks' [G.7714.1] defines a | ||||
protocol and procedure for transport plane layer adjacency discovery | ||||
(e.g. discovering the transport plane layer end point relationships | ||||
and verifying their connectivity). The ITU-T is currently working to | ||||
extend discovery to control plane aspects providing detail on a | ||||
Discovery framework architecture in G.8080 and a new Recommendation | ||||
on 'Control plane initial establishment, reconfiguration'. | ||||
3. Transport Network Architecture | 3. Transport Network Architecture | |||
A generic functional architecture for transport networks is defined | A generic functional architecture for transport networks is defined | |||
in the International Telecommunications Union (ITU-T) recommendation | in International Telecommunication Union (ITU-T) Recommendation | |||
[G.805]. This recommendation describes the functional architecture | [G.805]. This recommendation describes the functional architecture | |||
of transport networks in a technology independent way. This | of transport networks in a technology-independent way. This | |||
architecture forms the basis for a set of technology specific | architecture forms the basis for a set of technology-specific | |||
architectural recommendations for transport networks (e.g., SDH, | architectural recommendations for transport networks (e.g., SDH, PDH, | |||
PDH, OTN, etc.) | OTN, etc.). | |||
The architecture defined in G.805 is designed using a layered model | The architecture defined in G.805 is designed using a layered model | |||
with a client-server relationship between layers. The architecture | with a client-server relationship between layers. The architecture | |||
is recursive in nature; a network layer is both a server to the | is recursive in nature; a network layer is both a server to the | |||
client layer above it and a client to the server layer below it. | client layer above it and a client to the server layer below it. | |||
There are two basic building blocks defined in G.805: "subnetworks" | There are two basic building blocks defined in G.805: "subnetworks" | |||
and "links". A subnetwork is defined as a set of ports which are | and "links". A subnetwork is defined as a set of ports that are | |||
available for the purpose of routing "characteristic information". A | available for the purpose of routing "characteristic information". A | |||
link consists of a subset of ports at the edge of one subnetwork (or | link consists of a subset of ports at the edge of one subnetwork (or | |||
"access group") and is associated with a corresponding subset of | "access group") and is associated with a corresponding subset of | |||
ports at the edge of another subnetwork or access group. | ports at the edge of another subnetwork or access group. | |||
Two types of connections are defined in G.805: "link connection" | Two types of connections are defined in G.805: link connection (LC) | |||
(LC) and "subnetwork connection" (SNC). A link connection is a fixed | and subnetwork connection (SNC). A link connection is a fixed and | |||
inflexible connection, while a subnetwork connection is flexible and | ||||
D. Fedyk, Editor Informational 4 | is set up and released using management or control plane procedures. | |||
and inflexible connection, while a subnetwork connection is flexible | A network connection is defined as a concatenation of subnetwork and | |||
and is setup and released using management or control plane | link connections. Figure 1 illustrates link and subnetwork | |||
procedures. A network connection is defined as a concatenation of | connections. | |||
subnetwork and link connections. Figure 1 illustrates link and | ||||
subnetwork connections. | ||||
(++++++++) (++++++++) | (++++++++) (++++++++) | |||
( SNC ) LC ( SNC ) | ( SNC ) LC ( SNC ) | |||
(o)--------(o)----------(o)--------(o) | (o)--------(o)----------(o)--------(o) | |||
( ) CP CP ( ) | ( ) CP CP ( ) | |||
(++++++++) (++++++++) | (++++++++) (++++++++) | |||
subnetwork subnetwork | subnetwork subnetwork | |||
Figure 1: Subnetwork and Link Connections | Figure 1: Subnetwork and Link Connections | |||
G.805 defines a set of reference points for the purpose of | G.805 defines a set of reference points for the purpose of | |||
identification in both the management and the control plane. These | identification in both the management and the control planes. These | |||
identifiers are NOT required to be the same. A link connection or a | identifiers are NOT required to be the same. A link connection or a | |||
subnetwork connection is delimited by connection points (CP). A | subnetwork connection is delimited by connection points (CPs). A | |||
network connection is delimited by a termination connection point | network connection is delimited by a termination connection point | |||
(TCP). A link connection in the client layer is represented by a | (TCP). A link connection in the client layer is represented by a | |||
pair of adaptation functions and a trail in the server layer | pair of adaptation functions and a trail in the server layer network. | |||
network. A trail represents the transfer of monitored adapted | A trail represents the transfer of monitored adapted characteristics | |||
characteristics information of the client layer network between | information of the client layer network between access points (APs). | |||
access points (AP). A trail is delimited by two access points, one | ||||
at each end of the trail. Figure 2 shows a network connection and | A trail is delimited by two access points, one at each end of the | |||
its relationship with link and subnetwork connections. Figure 2 also | trail. Figure 2 shows a network connection and its relationship with | |||
shows the CP and TCP reference points. | link and subnetwork connections. Figure 2 also shows the CP and TCP | |||
reference points. | ||||
D. Fedyk, Editor Informational 5 | ||||
|<-------Network Connection---------->| | |<-------Network Connection---------->| | |||
| | | | | | |||
| (++++++++) (++++++++) | | | (++++++++) (++++++++) | | |||
|( SNC ) LC ( SNC ) | | |( SNC ) LC ( SNC ) | | |||
(o)--------(o)----------(o)--------(o)| | (o)--------(o)----------(o)--------(o)| | |||
TCP( )| CP CP |( )TCP | TCP( )| CP CP |( )TCP | |||
(++++++++) | | (++++++++) | (++++++++) | | (++++++++) | |||
| | | | | | |||
| Trail | | | Trail | | |||
|<-------->| | |<-------->| | |||
| | | | | | |||
--- --- | --- --- | |||
\ / \ / | \ / \ / | |||
- - | - - | |||
AP 0 0 AP | AP 0 0 AP | |||
| | | | | | |||
(oo)------(oo) | (oo)------(oo) | |||
For management plane purposes the G.805 reference points are | Figure 2: Network Connection with Link and Subnetwork Connections | |||
For management plane purposes, the G.805 reference points are | ||||
represented by a set of management objects described in ITU-T | represented by a set of management objects described in ITU-T | |||
recommendation M.3100 [M.3100]. Connection termination points (CTP) | Recommendation M.3100 [M.3100]. Connection termination points (CTPs) | |||
and trail termination points (TTP) are the management plane objects | and trail termination points (TTPs) are the management plane objects | |||
for CP and TCP respectively. | for CP and TCP, respectively. | |||
In the same way as in M.3100, the transport resources in G.805 are | In the same way as in M.3100, the transport resources in G.805 are | |||
identified for the purposes of the control plane by entities | identified for the purposes of the control plane by entities suitable | |||
suitable for connection control. G.8080 introduces the reference | for connection control. G.8080 introduces the reference architecture | |||
architecture for the control plane of the automatic switched optical | for the control plane of the Automatic Switched Optical Networks | |||
networks (ASON). G.8080 introduces a set of reference points | (ASONs). G.8080 introduces a set of reference points relevant to the | |||
relevant to the ASON control plane and their relationship to the | ASON control plane and their relationship to the corresponding points | |||
corresponding points in the transport plane. A Subnetwork point | in the transport plane. A subnetwork point (SNP) is an abstraction | |||
(SNP) is an abstraction that represents an actual or potential | that represents an actual or potential underlying CP or an actual or | |||
underlying CP or an actual or potential TCP. A set of SNPs that are | potential TCP. A set of SNPs that are grouped together for the | |||
grouped together for the purpose of routing is called SNP pool | purpose of routing is called SNP pool (SNPP). Similar to LC and SNC, | |||
(SNPP). Similar to LC and SNC, the SNP-SNP relationship may be | the SNP-SNP relationship may be static and inflexible (this is | |||
static and inflexible (this is referred to as an SNP link | referred to as an SNP link connection), or it can be dynamic and | |||
connection) or it can be dynamic and flexible (this is referred to | flexible (this is referred to as an SNP subnetwork connection). | |||
as a SNP subnetwork connection). | ||||
3.1 G.8080 Discovery Framework | 3.1. G.8080 Discovery Framework | |||
G.8080 provides a reference control plane architecture based on the | G.8080 provides a reference control plane architecture based on the | |||
descriptive use of functional components representing abstract | descriptive use of functional components representing abstract | |||
entities and abstract component interfaces. The description is | entities and abstract component interfaces. The description is | |||
generic and no particular physical partitioning of functions is | generic, and no particular physical partitioning of functions is | |||
implied. The input/output information flows associated with the | implied. The input/output information flows associated with the | |||
functional components serve for defining the functions of the | functional components serve for defining the functions of the | |||
components and are considered to be conceptual, not physical. | components and are considered to be conceptual, not physical. | |||
Components can be combined in different ways and the description is | Components can be combined in different ways, and the description is | |||
not intended to limit implementations. Control plane discovery is | not intended to limit implementations. Control plane discovery is | |||
D. Fedyk, Editor Informational 6 | ||||
described in G.8080 by using three components: Discovery Agent (DA), | described in G.8080 by using three components: Discovery Agent (DA), | |||
Termination and Adaptation Performer (TAP), and Link Resource | Termination and Adaptation Performer (TAP), and Link Resource Manager | |||
Manager (LRM). | (LRM). | |||
The objective of the discovery framework in G.8080 is to establish | The objective of the discovery framework in G.8080 is to establish | |||
the relationship between CP-CP link connections (transport plane) | the relationship between CP-CP link connections (transport plane) and | |||
and SNP-SNP link connections (control plane). The fundamental | SNP-SNP link connections (control plane). The fundamental | |||
characteristics of G.8080 discovery framework is the functional | characteristics of G.8080 discovery framework is the functional | |||
separation between the control and the transport plane discovery | separation between the control and the transport plane discovery | |||
processes and name spaces. From G.8080: "This separation allows | processes and name spaces. From G.8080: "This separation allows | |||
control plane names to be completely separate from transport plane | control plane names to be completely separate from transport plane | |||
names, and completely independent of the method used to populate the | names, and completely independent of the method used to populate the | |||
DAs with those transport names." "In order to assign an SNP-SNP link | DAs with those transport names. In order to assign an SNP-SNP link | |||
connection to an SNPP link, it is only necessary for the transport | connection to an SNPP link, it is only necessary for the transport | |||
name for the link connection to exist". Thus, it is possible to | name for the link connection to exist". Thus, it is possible to | |||
assign link connections to the control plane without the link | assign link connections to the control plane without the link | |||
connection being physically connected. | connection being physically connected. | |||
Discovery encompasses two separate processes: (1) transport plane | Discovery encompasses two separate processes: (1) transport plane | |||
discovery, i.e. CP-to-CP and TCP-to-TCP connectivity and (2) control | discovery, i.e., CP-to-CP and TCP-to-TCP connectivity; and (2) | |||
plane discovery, i.e. SNP-to-SNP and SNPP links. | control plane discovery, i.e., SNP-to-SNP and SNPP links. | |||
G.8080 Amendment 1 defines the discovery agent (DA) as the entity | G.8080 Amendment 1 defines the Discovery Agent (DA) as the entity | |||
responsible for discovery in the transport plane. The DA operates in | responsible for discovery in the transport plane. The DA operates in | |||
the transport name space only and in cooperation with the | the transport name space only and in cooperation with the Termination | |||
Termination and Adaptation performer [TAP], provides the separation | and Adaptation Performer (TAP), provides the separation between that | |||
between that space and the control plane names. A local DA is only | space and the control plane names. A local DA is only aware of the | |||
aware of the CPs and TCPs that are assigned to it. The DA holds the | CPs and TCPs that are assigned to it. The DA holds the CP-CP link | |||
CP-CP link connection in the transport plane to enable SNP-SNP link | connection in the transport plane to enable SNP-SNP link connections | |||
connections to be bound to them at a later time by the TAP. The CP- | to be bound to them at a later time by the TAP. The CP-CP | |||
CP relationship may be discovered (e.g. per G.7714.1) or provided by | relationship may be discovered (e.g., per G.7714.1) or provided by a | |||
a management system. | management system. | |||
Control plane discovery takes place entirely within the control | Control plane discovery takes place entirely within the control plane | |||
plane name space (SNPs). The Link Resource Manager (LRM) holds the | name space (SNPs). The Link Resource Manager (LRM) holds the SNP-SNP | |||
SNP-SNP binding information necessary for the control plane name of | binding information necessary for the control plane name of the link | |||
the link connection, while the termination adaptation performer | connection, while the termination adaptation performer (TAP) holds | |||
(TAP) holds the relation between the control plane name (SNP) and | the relation between the control plane name (SNP) and the transport | |||
the transport plane name (CP) of the resource. Figure 3 shows the | plane name (CP) of the resource. Figure 3 shows the relationship and | |||
relationship and the different entities for transport and control | the different entities for transport and control discoveries. | |||
discoveries. | ||||
D. Fedyk, Editor Informational 7 | ||||
LRM LRM | LRM LRM | |||
+-----+ holds SNP-SNP Relation +-----+ | +-----+ holds SNP-SNP Relation +-----+ | |||
| |-------------------------| | | | |-------------------------| | | |||
+-----+ +-----+ | +-----+ +-----+ | |||
| | | | | | |||
v v | v v | |||
+-----+ +-----+ | +-----+ +-----+ | |||
| o | SNP's in SNPP | o | | | o | SNPs in SNPP | o | | |||
| | | | | | | | | | |||
| o | | o | | | o | | o | | |||
| | | | | | | | | | |||
| o | | o | | | o | | o | | |||
+-----+ +-----+ | +-----+ +-----+ | |||
| | | | | | |||
v v Control Plane | v v Control Plane | |||
+-----+ +-----+ Discovery | +-----+ +-----+ Discovery | |||
| | Termination and | | | | | Termination and | | | |||
---|-----|-------------------------|-----|--------- | ---|-----|-------------------------|-----|--------- | |||
skipping to change at line 368 | skipping to change at page 9, line 7 | |||
| | | | | | | | | | | | | | |||
| +-----+ +-----+ | | | +-----+ +-----+ | | |||
| / \ | | | / \ | | |||
V/ \V | V/ \V | |||
O CP (Transport Name) O CP (Transport Name) | O CP (Transport Name) O CP (Transport Name) | |||
Figure 3: Discovery in the Control and the Transport Planes | Figure 3: Discovery in the Control and the Transport Planes | |||
4. Discovery Technologies | 4. Discovery Technologies | |||
4.1 Generalized automatic discovery techniques G.7714 | 4.1. Generalized Automatic Discovery Techniques G.7714 | |||
Generalized automatic discovery techniques are described in G.7714 | Generalized automatic discovery techniques are described in G.7714 to | |||
to aid resource management and routing for G.8080. The term routing | aid resource management and routing for G.8080. The term routing | |||
here is described in the transport context of routing connections in | here is described in the transport context of routing connections in | |||
an optical network as opposed to the routing context typically | an optical network as opposed to the routing context typically | |||
associated in packet networks. | associated in packet networks. | |||
G.7714 is concerned with two types of discovery: | G.7714 is concerned with two types of discovery: | |||
- Layer adjacency discovery | - Layer adjacency discovery | |||
- Physical media adjacency discovery | - Physical media adjacency discovery | |||
Layer adjacency discovery can be used to correlate physical | Layer adjacency discovery can be used to correlate physical | |||
connections with management configured attributes. Among other | connections with management configured attributes. Among other | |||
features this capability allows reduction in configuration and the | features this capability allows reduction in configuration and the | |||
detection of miswired equipment. | detection of mis-wired equipment. | |||
D. Fedyk, Editor Informational 8 | ||||
Physical media adjacency discovery is a process that allows the | Physical media adjacency discovery is a process that allows the | |||
physical testing of the media for the purpose of inventory capacity | physical testing of the media for the purpose of inventory capacity | |||
and verifying the port characteristics of physical media adjacent | and verifying the port characteristics of physical media adjacent | |||
networks. | networks. | |||
G.7714 does not specify specific protocols but rather the type of | G.7714 does not specify specific protocols but rather the type of | |||
techniques that can be used. G.7714.1 specifies a protocol for | techniques that can be used. G.7714.1 specifies a protocol for layer | |||
layer adjacency with respect to SDH and OTN networks for Layer | adjacency with respect to SDH and OTN networks for layer adjacency | |||
adjacency Discovery. A GMPLS method for Layer Discovery using | discovery. A GMPLS method for layer discovery using elements of LMP | |||
elements of LMP is included in this set of procedures. | is included in this set of procedures. | |||
An important point about the G.7714 specification is it specifies a | An important point about the G.7714 specification is that it | |||
discovery mechanism for optical networks but not necessarily how the | specifies a discovery mechanism for optical networks but not | |||
information will be used. It is intended that the Transport | necessarily how the information will be used. It is intended that | |||
Management plane or a Transport control plane may subsequently make | the transport management plane or a transport control plane may | |||
use of the discovered information. | subsequently make use of the discovered information. | |||
4.2 LMP and G.8080 Terminology Mapping | 4.2. LMP and G.8080 Terminology Mapping | |||
GMPLS is a set of IP-based protocols, including LMP, providing a | GMPLS is a set of IP-based protocols, including LMP, providing a | |||
control plane for multiple data plane technologies, including | control plane for multiple data plane technologies, including | |||
optical/transport networks and their resources (i.e. wavelengths, | optical/transport networks and their resources (i.e., wavelengths, | |||
timeslots, etc.) and without assuming any restriction on the control | timeslots, etc.) and without assuming any restriction on the control | |||
plane architecture (see [GMPLS-ARCH]). Whereas, G.8080 defines a | plane architecture (see [RFC3945]). On the other hand, G.8080 | |||
control plane reference architecture for optical/transport networks | defines a control plane reference architecture for optical/transport | |||
and without any restriction on the control plane implementation. | networks without any restriction on the control plane implementation. | |||
Being developed in separate standards forums, and with different | Being developed in separate standards forums, and with different | |||
scope, they use different terms and definitions. | scopes, they use different terms and definitions. | |||
Terminology mapping between LMP and ASON (G.805/G.8080) is an | Terminology mapping between LMP and ASON (G.805/G.8080) is an | |||
important step towards the understanding of the two architectures | important step towards the understanding of the two architectures and | |||
and allows for potential cooperation in areas where cooperation is | allows for potential cooperation in areas where cooperation is | |||
possible. To facilitate this mapping, we differentiate between the | possible. To facilitate this mapping, we differentiate between the | |||
two types of data links in LMP. According to LMP, a data link may be | two types of data links in LMP. According to LMP, a data link may be | |||
considered by each node that it terminates on as either a 'port' or | considered by each node that it terminates on as either a 'port' or a | |||
a 'component link'. The LMP notions of port and component link are | 'component link'. The LMP notions of port and component link are | |||
supported by the G.805/G.8080 architecture. G.8080's variable | supported by the G.805/G.8080 architecture. G.8080's variable | |||
adaptation function is broadly equivalent to LMP's component link, | adaptation function is broadly equivalent to LMP's component link, | |||
i.e. a single server layer trail dynamically supporting different | i.e., a single server-layer trail dynamically supporting different | |||
multiplexing structures. Note that when the data plane delivers its | multiplexing structures. Note that when the data plane delivers its | |||
own addressing space, LMP Interface_IDs and Data Links IDs are used | own addressing space, LMP Interface_IDs and Data Links IDs are used | |||
as handles by the control plane to the actual CP Name and CP-to-CP | as handles by the control plane to the actual CP Name and CP-to-CP | |||
Name, respectively. | Name, respectively. | |||
The terminology mapping is summarized in the following table: | The terminology mapping is summarized in the following table: Note | |||
Note that the table maps ASON terms to GMPLS terms that refer to | that the table maps ASON terms to GMPLS terms that refer to | |||
equivalent objects, but in many cases there is not a one to one | equivalent objects, but in many cases there is not a one-to-one | |||
mapping. Additional information beyond Discovery terminology can be | mapping. Additional information beyond discovery terminology can be | |||
found in [LEXICO]. | found in [LEXICO]. | |||
D. Fedyk, Editor Informational 9 | ||||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms | | | ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms | | |||
| | Port | Component Link | | | | Port | Component Link | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| CP | TE Resource; | TE Resource; | | | CP | TE Resource; | TE Resource; | | |||
| | Interface (Port) | Interface. | | | | Interface (Port) | Interface. | | |||
| | |(Comp. link) | | | | |(Comp. link) | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| CP Name | Interface ID | Interface ID(s) | | | CP Name | Interface ID | Interface ID(s) | | |||
| | no further sub- | resources (such as| | | | no further sub- | resources (such as| | |||
skipping to change at line 475 | skipping to change at page 11, line 43 | |||
| | (Port) | (Comp. Link) | | | | (Port) | (Comp. Link) | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| SNPP Name | Link ID | Link ID | | | SNPP Name | Link ID | Link ID | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| SNPP Link | TE Link | TE Link | | | SNPP Link | TE Link | TE Link | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
| SNPP Link Name | TE Link ID | TE Link ID | | | SNPP Link Name | TE Link ID | TE Link ID | | |||
+----------------+--------------------+-------------------+ | +----------------+--------------------+-------------------+ | |||
where composite identifiers are: | where composite identifiers are: | |||
- Data Link ID: <Local Interface ID; Remote Interface ID> | - Data Link ID: <Local Interface ID; Remote Interface ID> | |||
- TE Link ID: <Local Link ID; Remote Link ID> | - TE Link ID: <Local Link ID; Remote Link ID> | |||
Composite Identifiers are defined in the LMP draft [LMP]. LMP | Composite Identifiers are defined in the RFC 4204 [LMP]. LMP | |||
discovers Data Links and identifies them by the pair of local and | discovers data links and identifies them by the pair of local and | |||
remote interface Ids. TE Links are comprised of Data Links or | remote interface IDs. TE links are composed of data links or | |||
component TE links. TE links are similarly identified by pair of | component TE links. TE links are similarly identified by pair of | |||
local and remote Link ID. | local and remote link ID. | |||
4.2.1 TE Link Definition and Scope | 4.2.1. TE Link Definition and Scope | |||
D. Fedyk, Editor Informational 10 | ||||
In the table, TE link/resource is equated with the concept of SNP, | In the table, TE link/resource is equated with the concept of SNP, | |||
SNP LC, SNPP and SNPP link. The definition of the TE link is broad in | SNP LC, SNPP, and SNPP link. The definition of the TE link is broad | |||
scope and it is useful to repeat it here. The original definition | in scope, and it is useful to repeat it here. The original | |||
appears in [GMPLS-RTG]: | definition appears in [GMPLS-RTG]: | |||
"A TE link is a logical construct that represents a way to group/map | "A TE link is a logical construct that represents a way to group/map | |||
the information about certain physical resources (and their | the information about certain physical resources (and their | |||
properties) that interconnects LSRs into the information that is | properties) that interconnects LSRs into the information that is used | |||
used by Constrained SPF for GMPLS path computation, and GMPLS | by Constrained SPF for GMPLS path computation, and GMPLS signaling". | |||
signaling." | ||||
While this definition is concise it is probably worth pointing out | While this definition is concise, it is probably worth pointing out | |||
some of the implications of the definition. | some of the implications of the definition. | |||
A component of the TE link may follow different path between the | A component of the TE link may follow different paths between the | |||
pair of LSRs. For example, a TE link comprising multiple STS-3cs, | pair of LSRs. For example, a TE link comprising multiple STS-3cs, | |||
the individual STS-3cs component links may take identical or | the individual STS-3cs component links may take identical or | |||
different physical (OC-3 and/or OC-48) paths between LSRs. | different physical (OC-3 and/or OC-48) paths between LSRs. | |||
The TE link construct is a logical construction encompassing many | The TE link construct is a logical construction encompassing many | |||
layers in networks [RFC 3471]. A TE link can represent either | layers in networks [RFC 3471]. A TE link can represent either | |||
unallocated potential or allocated actual resources. Further | unallocated potential or allocated actual resources. Further | |||
allocation is represented by Bandwidth reservation and the resources | allocation is represented by bandwidth reservation, and the resources | |||
may be real or in the case of packets, virtual to allow for over | may be real or, in the case of packets, virtual to allow for | |||
booking or other forms of statistical multiplexing schemes. | overbooking or other forms of statistical multiplexing schemes. | |||
Since TE links may represent large numbers of parallel resources | Since TE links may represent large numbers of parallel resources, | |||
they can be bundled for efficient summarization of resource | they can be bundled for efficient summarization of resource capacity. | |||
capacity. Typically bundling represents a logical TE link resource | Typically, bundling represents a logical TE link resource at a | |||
at a particular Interface Switching Capability. Once TE link | particular Interface Switching Capability. Once TE link resources | |||
resources are allocated the actual capacity may be represented as | are allocated, the actual capacity may be represented as LSP | |||
LSP hierarchical (tunneled) TE link capability in another logical TE | hierarchical (tunneled) TE link capability in another logical TE link | |||
link [HIER]. | [HIER]. | |||
TE links also incorporate the notion of a Forwarding Adjacency (FA) | TE links also incorporate the notion of a Forwarding Adjacency (FA) | |||
and Interface Switching Capability [RFC3945]. The FA allows | and Interface Switching Capability [RFC3945]. The FA allows | |||
transport resources to be represented as TE-links. The Interface | transport resources to be represented as TE links. The Interface | |||
Switching Capability specifies the type of transport capability such | Switching Capability specifies the type of transport capability such | |||
as Packet Switch Capable(PSC), Layer-2 Switch Capable (L2SC), | as Packet Switch Capable (PSC), Layer-2 Switch Capable (L2SC), Time- | |||
Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and | Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber- | |||
Fiber-Switch Capable (FSC). | Switch Capable (FSC). | |||
A TE link between GMPLS controlled optical nodes may consist of a | ||||
bundled (TE link) which itself consists of a mix of point-to-point | ||||
component links [BUNDLE]. A TE link is identified by the tuple: | ||||
(link Identifier (32 bit number), Component link Identifier (32 bit | ||||
number) and generalized label (media specific)). | ||||
D. Fedyk, Editor Informational 11 | A TE link between GMPLS-controlled optical nodes may consist of a | |||
bundled TE link, which itself consists of a mix of point-to-point | ||||
component links [BUNDLE]. A TE link is identified by the tuple (link | ||||
Identifier (32-bit number), Component link Identifier (32-bit | ||||
number), and generalized label (media specific)). | ||||
4.3 LMP and G.8080 Discovery Relationship | 4.3. LMP and G.8080 Discovery Relationship | |||
LMP currently consists of four primary procedures, of which, the | LMP currently consists of four primary procedures, of which the first | |||
first two are mandatory and the last two are optional: | two are mandatory and the last two are optional: | |||
1. Control channel management | 1. Control channel management | |||
2. Link property correlation | 2. Link property correlation | |||
3. Link verification | 3. Link verification | |||
4. Fault management | 4. Fault management | |||
LMP procedures that are relevant to G.8080 control plane discovery | LMP procedures that are relevant to G.8080 control plane discovery | |||
are control channel management, link property correlation and Link | are control channel management, link property correlation, and link | |||
Verification. Key to understanding G.8080 discovery aspects in | verification. Key to understanding G.8080 discovery aspects in | |||
relation to [LMP] is that LMP procedures are specific for an | relation to [LMP] is that LMP procedures are specific for an IP-based | |||
IP-based control plane abstraction of the transport plane. | control plane abstraction of the transport plane. | |||
LMP control channel management is used to establish and maintain | LMP control channel management is used to establish and maintain | |||
control channel connectivity between LMP adjacent nodes. In GMPLS, | control channel connectivity between LMP adjacent nodes. In GMPLS, | |||
the control channels between two adjacent nodes are not required to | the control channels between two adjacent nodes are not required to | |||
use the same physical medium as the TE links between those nodes. | use the same physical medium as the TE links between those nodes. | |||
The control channels that are used to exchange the GMPLS control | The control channels that are used to exchange the GMPLS control | |||
plane information exist independently of the TE links they manage | plane information exist independently of the TE links they manage | |||
(i.e., control channels may be in-band or out-of-band, provided the | (i.e., control channels may be in-band or out-of-band, provided the | |||
associated control points terminate the LMP packets). The Link | associated control points terminate the LMP packets). The Link | |||
Management Protocol [LMP] was designed to manage TE links, | Management Protocol [LMP] was designed to manage TE links, | |||
independently of the physical medium capabilities of the data links. | independently of the physical medium capabilities of the data links. | |||
Link property correlation is used to aggregate multiple data links | Link property correlation is used to aggregate multiple data links | |||
into a single TE Link and to synchronize the link properties. | into a single TE link and to synchronize the link properties. | |||
Link verification is used to verify the physical connectivity of the | Link verification is used to verify the physical connectivity of the | |||
data links and verify the mapping of the Interface-ID to Link-ID (CP | data links and verify the mapping of the Interface-ID to Link-ID (CP | |||
to SNP). The local-to-remote associations can be obtained using a | to SNP). The local-to-remote associations can be obtained using a | |||
priori knowledge or using the Link verification procedure. | priori knowledge or using the link verification procedure. | |||
Fault management is primarily used to suppress alarms and to | Fault management is primarily used to suppress alarms and to localize | |||
localize failures. It is an optional LMP procedure, its use will | failures. It is an optional LMP procedure; its use will depend on | |||
depend on the specific technology's capabilities. | the specific technology's capabilities. | |||
[LMP] supports distinct transport and control plane name spaces with | [LMP] supports distinct transport and control plane name spaces with | |||
the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE | the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE | |||
object allows transport plane names to be associated with interface | object allows transport plane names to be associated with interface | |||
identifiers [LMP-TEST]. | identifiers [LMP-TEST]. | |||
Aspects of LMP link verification appear similar to G.7714.1 | Aspects of LMP link verification appear similar to G.7714.1 | |||
discovery, however the two procedures are different. G.7714.1 | discovery; however, the two procedures are different. G.7714.1 | |||
provides discovery of the transport plane layer adjacencies. It | provides discovery of the transport plane layer adjacencies. It | |||
provides a generic procedure to discover the connectivity of two end | provides a generic procedure to discover the connectivity of two | |||
points in the transport plane. Whereas, LMP link verification | endpoints in the transport plane. On the other hand, the LMP link | |||
procedure is a control plane driven procedure and assumes either (1) | verification procedure is a control-plane-driven procedure and | |||
a priori knowledge of the associated data plane's local and remote | assumes either (1) a priori knowledge of the associated data plane's | |||
end point connectivity and Interface_IDs (e.g. via management plane | local and remote endpoint connectivity and Interface_IDs (e.g., via | |||
or use of G.7714.1), or (2) support of the remote node for | management plane or use of G.7714.1), or (2) support of the remote | |||
node for associating the data interface being verified with the | ||||
D. Fedyk, Editor Informational 12 | content of the TRACE object (inferred mapping). For SONET/SDH | |||
associating the data interface being verified with the content of | transport networks, LMP verification uses the SONET/SDH Trail Trace | |||
the TRACE object (inferred mapping). For SONET/SDH transport | identifier (see [G.783]). | |||
networks, LMP verification uses the SONET/SDH Trail Trace identifier | ||||
(see [G.783]). | ||||
G.7714.1 supports the use of transport plane discovery independent | G.7714.1 supports the use of transport plane discovery independent of | |||
of the platform using the capability. Furthermore G.7714.1 specifies | the platform using the capability. Furthermore, G.7714.1 specifies | |||
the use of a Discovery Agent that could be located in an external | the use of a Discovery Agent that could be located in an external | |||
system and the need to support the use of text-oriented man-machine | system and the need to support the use of text-oriented man-machine | |||
language to provide the interface. Therefore, G.7714.1 limits the | language to provide the interface. Therefore, G.7714.1 limits the | |||
discovery messages to printable characters defined by [T.50] and | discovery messages to printable characters defined by [T.50] and | |||
requires Base64 encoding for the TCP-ID and DA ID. External | requires Base64 encoding for the TCP-ID and DA ID. External name- | |||
name-servers may be used to resolve the G.7714.1 TCP name, allowing | servers may be used to resolve the G.7714.1 TCP name, allowing the | |||
the TCP to have an IP, NSAP or any other address format. Whereas, | TCP to have an IP, Network Service Access Protocol (NSAP), or any | |||
LMP is based on the use of an IP-based control plane, and the LMP | other address format. On the other hand, LMP is based on the use of | |||
interface ID uses IPv4, IPv6, or unnumbered interface IDs. | an IP-based control plane, and the LMP interface ID uses IPv4, IPv6, | |||
or unnumbered interface IDs. | ||||
4.4 Comparing LMP and G.8080 | 4.4. Comparing LMP and G.8080 | |||
LMP exists to support GMPLS TE resource and TE link discovery. In | LMP exists to support GMPLS TE resource and TE link discovery. In | |||
section 4.2.1 we elaborated on the definition of the TE link. LMP | section 4.2.1, we elaborated on the definition of the TE link. LMP | |||
enables the aspects of TE links to be discovered, and reported to | enables the aspects of TE links to be discovered and reported to the | |||
the control plane, more specifically the routing plane. G.8080 and | control plane, more specifically, the routing plane. G.8080 and | |||
G.7714 are agnostic to the type of control plane and discovery | G.7714 are agnostic to the type of control plane and discovery | |||
protocol used. LMP is a valid realization of a control plane | protocol used. LMP is a valid realization of a control plane | |||
discovery process under a G.8080 model. | discovery process under a G.8080 model. | |||
G.7714 specifies transport plane discovery with respect to the | G.7714 specifies transport plane discovery with respect to the | |||
transport layer CTPs or TCPs using ASON conventions and naming for | transport layer CTPs or TCPs using ASON conventions and naming for | |||
the elements of the ASON control plane and the ASON management | the elements of the ASON control plane and the ASON management plane. | |||
plane. This discovery supports a centralized management model of | This discovery supports a centralized management model of | |||
configuration as well as a distributed control plane model, in other | configuration as well as a distributed control plane model; in other | |||
words discovered items can be reported to the management plane or | words, discovered items can be reported to the management plane or | |||
the control plane. G.7714.1 provides one realization of a transport | the control plane. G.7714.1 provides one realization of a transport | |||
plane discovery process. | plane discovery process. | |||
Today LMP and G.7714, G7714.1 are defined in different Standards | Today, LMP and G.7714, G7714.1 are defined in different standards | |||
Organizations. They have evolved out of different naming schemes | organizations. They have evolved out of different naming schemes and | |||
and architectural concepts. Whereas G.7714.1 supports a transport | architectural concepts. Whereas G.7714.1 supports a transport plane | |||
plane layer adjacency connectivity verification which can be used by | layer adjacency connectivity verification that can be used by a | |||
a control plane or a management plane, LMP is a control plane | control plane or a management plane, LMP is a control plane procedure | |||
procedure for managing GMPLS TE links (GMPLS's control plane | for managing GMPLS TE links (GMPLS's control plane representation of | |||
representation of the transport plane connections). | the transport plane connections). | |||
5. Security Considerations | 5. Security Considerations | |||
Since this document is purely descriptive in nature it does not | Since this document is purely descriptive in nature, it does not | |||
introduce any security issues. | introduce any security issues. | |||
G.8080 and G.7714/G.7714.1 provide security as associated with the | G.8080 and G.7714/G.7714.1 provide security as associated with the | |||
Data Communications Network on which they are implemented. | Data Communications Network on which they are implemented. | |||
D. Fedyk, Editor Informational 13 | LMP is specified using IP, which provides security mechanisms | |||
LMP is specified using IP which provides security mechanisms | ||||
associated with the IP network on which it is implemented. | associated with the IP network on which it is implemented. | |||
6. IANA Considerations | 6. Informative References | |||
This informational document makes no requests for IANA action. | ||||
7. Intellectual Property Considerations | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed | ||||
to pertain to the implementation or use of the technology described | ||||
in this document or the extent to which any license under such | ||||
rights might or might not be available; nor does it represent that | ||||
it has made any independent effort to identify any such rights. | ||||
Information on the procedures with respect to rights in RFC | ||||
documents can be found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use | ||||
of such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository | ||||
at http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at ietf- | ||||
ipr@ietf.org. | ||||
D. Fedyk, Editor Informational 14 | ||||
8. References | ||||
8.1 Normative References | ||||
[BCP 78] S. Bradner, "Intellectual Property Rights in IETF | ||||
Technology", BCP 79, RFC 3667, February 2004. | ||||
[BCP 79] S. Bradner, "IETF Rights in Contributions", BCP 79, | ||||
RFC 3668, February 2004. | ||||
8.2 Informational References | ||||
[LMP] J.P.Lang (Editor), "Link Management Protocol," draft- | [LMP] Lang, J., "Link Management Protocol (LMP)", RFC 4204, | |||
ietf-ccamp-lmp-10.txt, October 2003. | October 2005. | |||
[LMP-TEST] J.P.Lang et al., "SONET/SDH Encoding for Link | [LMP-TEST] Lang, J. and D. Papadimitriou, "Synchronous Optical | |||
Management Protocol (LMP) Test messages," draft-ietf- | Network (SONET)/Synchronous Digital Hierarchy (SDH) | |||
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt, December | Encoding for Link Management Protocol (LMP) Test | |||
2004. | Messages", RFC 4207, October 2005. | |||
[RFC3945] Eric Mannie (Editor), "Generalized Multi-protocol Label | [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching | |||
Switching Architecture," RFC3945, October 2004. | (GMPLS) Architecture", RFC 3945, October 2004. | |||
[RFC3471] Lou Berger (Editor), "Generalized Multi-Protocol Label | [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching | |||
Switching (GMPLS)Signaling Functional Description," | (GMPLS) Signaling Functional Description", RFC 3471, | |||
RFC3471, January 2003. | January 2003. | |||
[GMPLS-RTG] K. Kompella & Y. Rekhter (editors) "Routing Extensions | [GMPLS-RTG] Kompella, K. and Y. Rekhter, "Routing Extensions in | |||
in Support of Generalized Multi-Protocol Label | Support of Generalized Multi-Protocol Label Switching | |||
Switching", draft-ietf-ccamp-gmpls-routing-09.txt, | (GMPLS)", RFC 4202, October 2005. | |||
December 2003. | ||||
[HIER] K. Kompella & Y. Rekhter "LSP Hierarchy with Generalized | [HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | |||
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, | Hierarchy with Generalized Multi-Protocol Label Switching | |||
September 2002. | (GMPLS) Traffic Engineering (TE)", RFC 4206, October | |||
2005. | ||||
[BUNDLE] K. Kompella, Y. Rekhter, Lou Berger "Link Bundling in | [BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling | |||
MPLS Traffic Engineering", draft-ietf-mpls-bundle- | in MPLS Traffic Engineering (TE)", RFC 4201, October | |||
06.txt, December 2004. | 2005. | |||
[LEXICO] A. Farrel & I Bryskin "A Lexicography for the | [LEXICO] Bryskin, I. and A. Farrel, "A Lexicography for the | |||
Interpretation of Generalized Multiprotocol Label | Interpretation of Generalized Multiprotocol Label | |||
Switching (GMPLS) Terminology within The Context of the | Switching (GMPLS) Terminology within The Context of the | |||
ITU-T's Automatically Switched Optical Network (ASON) | ITU-T's Automatically Switched Optical Network (ASON) | |||
Architecture", draft-bryskin-ccamp-gmpls-ason- | Architecture", Work in Progress, January 2006. | |||
lexicography-02.txt, April 2005. | ||||
"For information on the availability of ITU-T Documents, please see | For information on the availability of the ITU-T documents, please | |||
http://www.itu.int" | see http://www.itu.int. | |||
D. Fedyk, Editor Informational 15 | ||||
[G.783] ITU-T G.783 (2004), Characteristics of synchronous | [G.783] ITU-T G.783 (2004), Characteristics of synchronous | |||
digital hierarchy (SDH) equipment functional blocks. | digital hierarchy (SDH) equipment functional blocks. | |||
[G.805] ITU-T G.805 (2000), Generic functional architecture of | [G.805] ITU-T G.805 (2000), Generic functional architecture of | |||
transport networks. | transport networks. | |||
[G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic | [G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic | |||
discovery techniques. | discovery techniques. | |||
[G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic | [G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic | |||
discovery in SDH and OTN networks. | discovery in SDH and OTN networks. | |||
[G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the | [G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the | |||
automatically switched optical network (ASON). | automatically switched optical network (ASON). | |||
[M.3100] ITU-T M.3100 (1995), Generic Network Information Model. | [M.3100] ITU-T M.3100 (1995), Generic Network Information Model. | |||
[T.50] ITU-T T.50 (1992), International Reference Alphabet. | [T.50] ITU-T T.50 (1992), International Reference Alphabet. | |||
9. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank Astrid Lozano, John Drake, Adrian | The authors would like to thank Astrid Lozano, John Drake, Adrian | |||
Farrel and Stephen Shew for their valuable comments. | Farrel and Stephen Shew for their valuable comments. | |||
The authors would like to thank ITU-T Study Group 15 Question 14 for | The authors would like to thank ITU-T Study Group 15 Question 14 for | |||
their careful review and comments. | their careful review and comments. | |||
10. Author's Addresses | Authors' Addresses | |||
Don Fedyk | Don Fedyk | |||
Nortel Networks | Nortel Networks | |||
600 Technology Park Drive | 600 Technology Park Drive | |||
Billerica, MA, 01821 | Billerica, MA, 01821 | |||
Phone: +1 978 288-3041 | Phone: +1 978 288-3041 | |||
Email: dwfedyk@nortel.com | EMail: dwfedyk@nortel.com | |||
Osama Aboul-Magd | Osama Aboul-Magd | |||
Nortel Networks | Nortel Networks | |||
P.O. Box 3511, Station 'C' | P.O. Box 3511, Station 'C' | |||
Ottawa, Ontario, Canada | Ottawa, Ontario, Canada | |||
K1Y-4H7 | K1Y-4H7 | |||
Phone: +1 613 763-5827 | Phone: +1 613 763-5827 | |||
Email: osama@nortel.com | EMail: osama@nortel.com | |||
D. Fedyk, Editor Informational 16 | ||||
Deborah Brungard | Deborah Brungard | |||
AT&T | AT&T | |||
Rm. D1-3C22 | Rm. D1-3C22 | |||
200 S. Laurel Ave. | 200 S. Laurel Ave. | |||
Middletown, NJ 07748, USA | Middletown, NJ 07748, USA | |||
Email: dbrungard@att.com | ||||
EMail: dbrungard@att.com | ||||
Jonathan P. Lang | Jonathan P. Lang | |||
Sonos, Inc. | Sonos, Inc. | |||
506 Chapala Street | 506 Chapala Street | |||
Santa Barbara, CA 93101 | Santa Barbara, CA 93101 | |||
Email : jplang@ieee.org | ||||
EMail : jplang@ieee.org | ||||
Dimitri Papadimitriou | Dimitri Papadimitriou | |||
Alcatel | Alcatel | |||
Francis Wellesplein, 1 | Francis Wellesplein, 1 | |||
B-2018 Antwerpen, Belgium | B-2018 Antwerpen, Belgium | |||
Phone: +32 3 240-84-91 | Phone: +32 3 240-84-91 | |||
Email: dimitri.papadimitriou@alcatel.be | EMail: dimitri.papadimitriou@alcatel.be | |||
11. Disclaimer of Validity | Full Copyright Statement | |||
This document and the information contained herein are provided on | Copyright (C) The Internet Society (2006). | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | ||||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | This document is subject to the rights, licenses and restrictions | |||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | contained in BCP 78, and except as set forth therein, the authors | |||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | retain all their rights. | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
12. Full Copyright Statement | Intellectual Property | |||
Copyright (C) The Internet Society (2005). This document is subject | The IETF takes no position regarding the validity or scope of any | |||
to the rights, licenses and restrictions contained in BCP 78, and | Intellectual Property Rights or other rights that might be claimed to | |||
except as set forth therein, the authors retain all their rights. | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
D. Fedyk, Editor Informational 17 | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgement | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 126 change blocks. | ||||
397 lines changed or deleted | 358 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |