One document matched: draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt
Differences from draft-zhang-ccamp-gmpls-g709-lmp-discovery-01.txt
Network Working Group Fatai Zhang
Internet Draft Dan Li
Category: Standards Track Huawei
D. Ceccarelli
D. Caviglia
Ericsson
Guoying Zhang
CATR
P.Grandi
S.Belotti
Alcatel-Lucent
Expires: April 2010 October 21, 2009
Link Management Protocol (LMP) extensions for G.709
Optical Transport Networks
draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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.
This Internet-Draft will expire on April 21, 2010.
Abstract
Recent progress of the Optical Transport Network (OTN) has introduced
new signal types (i.e., ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex)
and new Tributary Slot granularity (1.25Gbps).
Zhang Expires April 2010 [Page 1]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
Since equipments deployed prior to recently defined ITU-T
recommendations only support 2.5 Gbps Tributary Slot granularity and
ODU1, ODU2 and ODU3 containers, the compatibility problem should be
considered. In addition, a Higher Order ODU (HO ODU) link may not
support all the types of Lower Order ODU (LO ODU) signals defined by
the new OTN standards because of the limitation of the devices at the
two ends of a link. In these cases, the control plane is required to
run the capability discovering functions for the evolutive OTN.
This document describes the extensions to the Link Management
Protocol (LMP) needed to discover the capability of HO ODU link,
including the granularity of Tributary Slot to be used and the LO ODU
signal types that the link can support.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction.................................................3
2. Terminology..................................................3
3. Overview of the Evolutive G.709..............................4
3.1. Data Plane Backward Compatibility.......................5
4. Link Capability Discovery Requirements.......................6
4.1. Discovering the Granularity of the TS...................6
4.2. Discovering the Supported LO ODU Signal Types...........6
5. Extensions: LMP Link Summary Message.........................7
5.1. Message Extension.......................................8
5.1.1. LinkSummary Message................................8
5.1.2. LinkSummaryAck Message.............................8
5.1.3. LinkSummaryNack Message............................8
5.2. Object Definitions......................................9
5.3. Procedures.............................................11
6. Security Considerations.....................................12
7. IANA Considerations.........................................12
8. Acknowledgments.............................................12
9. References..................................................12
9.1. Normative References...................................12
9.2. Informative References.................................13
10. Authors' Addresses.........................................13
11. Contributors...............................................15
Zhang Expires April 2010 [Page 2]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
1. Introduction
The Link Management Protocol (LMP) defined in [RFC4204] is being
developed as part of the Generalized MPLS (GMPLS) protocol suite to
manage Traffic Engineering (TE) links.
Recently, great progress has been made for the Optical Transport
Networking (OTN) technologies in ITU-T. New ODU containers (i.e.,
ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex) and a new Tributary
Slot (TS) granularity (1.25Gbps) have been introduced by the [Gsup43]
and [G709-V3], enhancing the flexibility of OTNs.
With the evolution and deployment of G.709 technology, the backward
compatibility problem requires to be considered. In data plane, the
equipment supporting 1.25Gbps TS can combine the specific Tributary
Slots together (e.g., combination of TS#i and TS#i+4 on an HO ODU2
link) so that it can interwork with other equipments which support
2.5Gbps TS. From the control plane point of view, it is necessary to
discover which type of TS is supported at both ends of a link, so
that it can choose and reserve the TS resources correctly in this
link for the connection.
Additionally, the requirement of discovering the signal types of
Lower Order ODU (LO ODU) that can be supported by a Higher Order ODU
(HO ODU) should be taken into account. Equipment at one end of an HO
ODU link may not support to transport some types of LO ODU signals
(e.g., may not support the ODUflex). In this case, this HO ODU link
should not be selected for those types of LO ODU connections.
From the perspective of control plane, it is necessary to discover
the capability of an HO ODUk or OTUk link including the granularity
of TS to be used and the LO ODU signal types that the link can
support. Note that LO ODU type information can be, in principle,
discovered by routing. Since in certain case, routing is not present
(e.g. UNI case) we need to extend link management protocol
capabilities to cover this aspect. Obviously, in case of routing
presence, the discovering procedure by LMP could also be optional.
This document extends the LMP and describes the solution of
discovering HO ODU link capability.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Zhang Expires April 2010 [Page 3]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
3. Overview of the Evolutive G.709
The traditional OTN standard [ITUT-G709] describes the optical
transport hierarchy (OTH) and introduces three ODU signal types (i.e.,
ODU1, ODU2 and ODU3). The ODUj can be mapped into one or more
Tributary Slots (with a granularity of 2.5Gbps) of OPUk where j<k.
The ODUj can also be mapped into OTUj (j=1, 2 or 3) directly.
Recent revisions of ITU-T Recommendation G.709 have introduced new
features for Optical Transport Networks (OTN) ODU0, ODU4, ODU2e,
ODU3e1, ODU3e2 and ODUflex. The new features for the evolutive OTN
are described in the separate ITU-T documents. ODU0, ODU2e, ODU4 and
ODUflex are described in [G709-V3]. ODU3e1 and ODU3e2 are described
in [Gsup43].
The ITU-T documents also define the new multiplexing hierarchy for
the evolutive OTN. In this multiplexing hierarchy, LO ODUj can be
mapped into an OTUj, or multiplexed into an HO ODUk (where j<k) by
occupying several tributary slots.
In case of LO ODUj mapping into OTUj, the following mappings are
defined:
- ODU1 into OTU1 mapping
- ODU2 into OTU2 mapping
- ODU3 into OTU3 mapping
- ODU4 into OTU4 mapping
- ODU2e into OTU2e mapping
In case of LO ODUj multiplexing into HO ODUk, a new Tributary Slot
granularity (i.e., 1.25Gbps) is introduced in [G709-V3]. For the
evolutive OTN, the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex)
into an ODUk (k > j) signal can be depicted as follows:
- ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity)
- ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS
granularity)
- ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing
(with 1.25Gbps TS granularity)
Zhang Expires April 2010 [Page 4]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
- ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4
multiplexing (with 1.25Gbps TS granularity)
- ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity)
- ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity)
In order to be backward compatible with the 2.5Gbps TS defined in
[ITUT-G709], both the 2.5Gbps TS and the 1.25Gbps TS can be used in
the two cases listed below:
- ODU1 into ODU2 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
3.1. Data Plane Backward Compatibility
Equipment supporting a 1.25Gbps TS structure for OPU2 or OPU3 must be
backward compatible with equipment which supports only the 2.5G TS
structure. Specific Tributary Slots must be combined together (e.g.,
combination of TS#i and TS#i+4 on an HO ODU2 link) for the LO ODU at
one end of the HO ODU link which supports the 1.25Gbps TS structure,
so that the LO ODU can be carried on the HO ODU link correctly.
In the following example, suppose that the two ends of an ODU2 or
ODU3 link support different TS structure, where node A supports the
1.25Gbps TS structure, while node B supports the 2.5Gbps TS, as shown
in the figure below:
+-----+ +-----+
| | | |
| A +-------ODU2/ODU3 link-------+ B |
| | | |
+-----+ +-----+
(Support 1.25G TS) (Support 2.5G TS)
- In case of ODU1 multiplexing into ODU2, node A maps the ODU1 into
the TS#i and TS#i+4 (where i<=4) (with the granularity of 1.25Gbps)
of OPU2, so that node B can retrieve the ODU1 from the TS#i (with
the granularity of 2.5Gbps) of the OPU2, and vice versa.
- In case of ODU1 multiplexing into ODU3, node A maps the ODU1 into
the TS#i and TS#i+16 (where i<=16) (with the granularity of
Zhang Expires April 2010 [Page 5]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
1.25Gbps) of OPU3, so that node B can retrieve the ODU1 from the
TS#i (with the granularity of 2.5Gbps) of the OPU3, and vice versa.
- In case of ODU2 multiplexing into ODU3, node A maps the ODU2 into
the TS#a/TS#a+16, TS#b/TS#b+16, TS#c/TS#c+16 and TS#d/TS#d+16
(where a<b<c<d<=16) (with the granularity of 1.25Gbps) of OPU3, so
that node B can retrieve the ODU2 from the TS#a, TS#b, TS#c and
TS#d (with the granularity of 2.5Gbps) of the OPU3, and vice versa.
4. Link Capability Discovery Requirements
4.1. Discovering the Granularity of the TS
As described in section 3.1, if the two ends of a link use different
granularities of TS, The LO ODU must be mapped into specific combined
Tributary Slots in the end of link with TS of 1.25Gbps.
From the perspective of control plane, when creating a LO ODU
connection, the node MUST select and reserve specific TS for the
connection if the two ends of a link use different granularities of
TS. For example, for an ODU2 link, we suppose that node A only
supports the 2.5Gbps TS while node B supports the 1.25Gbps TS. When
node B receives a Path message from node A requesting an ODU1
connection, node B MUST reserve the TS#i and TS#i+4 (where i<=4)
(with the granularity of 1.25Gbps) and tell node A via the label
carried in the Resv message that the TS#i (with the granularity of
2.5Gbps) among the 4 slots has been reserved for the ODU1 connection.
Otherwise, the reservation procedure will fail.
+-----+ Path +-----+
| | ------------> | |
| A +-------ODU2 link-------+ B |
| | <------------- | |
+-----+ Resv +-----+
(Support 2.5G TS) (Support 1.25G TS)
Therefore, for an ODU2 or ODU3 link, in order to reserve TS resources
correctly for a LO ODU connection, the control plane of the two ends
MUST know which granularity the other end can support before creating
the LO ODU connection.
4.2. Discovering the Supported LO ODU Signal Types
Many new ODU signal types are introduced by [Gsup43] and [G709-V3],
such as ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. It is possible
that equipment does not always support all the LO ODU signal types
introduced by those new standards or drafts. If one end of an HO ODU
Zhang Expires April 2010 [Page 6]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
link can not support a certain LO ODU signal type and there is no HO
ODU FA LSP able to support this LO ODU signal, the HO ODU link/FA LSP
can not be selected to carry such type of LO ODU connection.
For example, in the following figure, if the interfaces IF1, IF2, IF8,
IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF
3 and IF4 can not support ODUflex signals. In this case, if one
ODUflex connection from A to C is requested, and there is no HO ODU
FA LSP from node A to C through node B, link #1 and #2 should be
excluded, link #3 and link #4 are the candidates (the possible path
could be A-D-C through link #3 and link #4).
+-----+
link #3 | | link #4
+-----------------+ D +-----------------+
| IF8| |IF7 |
| +-----+ |
| |
|IF1 IF6|
+--+--+ +-----+ +--+--+
| | link #1 | | link #2 | |
| A +--------------+ B +--------------+ C |
| |IF2 IF3| |IF4 IF5| |
+-----+ +-----+ +-----+
Therefore, it is necessary for the two ends of an HO ODU link to
discover which types of LO ODU can be supported by the HO ODU link.
After discovering, the capability information can be flooded by IGP,
so that the correct path for an ODU connection can be calculated.
5. Extensions: LMP Link Summary Message
[RFC4204] defines the Link Management Protocol (LMP) which consists
of four main procedures: control channel management, link property
correlation, link connectivity verification, and fault management. As
part of LMP, the link property correlation is used to verify the
consistency of the TE and data link information on both sides of a
link. This document extends the link property correlation procedure
to discover the capability of both sides of an HO ODU link.
The designated HO ODU overhead bytes (e.g., the GCC1 and GCC2
overhead bytes) can be used as the control channel to carry the LMP
message after the HO ODU link is created. The out-band Data
Communication Network (DCN) can also be used.
Zhang Expires April 2010 [Page 7]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
5.1. Message Extension
Three messages are used for link property correlation: LinkSummary,
LinkSummaryAck and LinkSummaryNack Message. This document does not
change the basic procedure of LMP but just add a new subobject (HO
ODU Link Capability Subobject) in the DATA_LINK object to carry the
capability of one end of an HO ODU link.
The formats of LinkSummary, LinkSummaryAck and LinkSummaryNack
messages are defined in [RFC4204].
5.1.1. LinkSummary Message
The local end of a TE link can send a LinkSummary message to the
remote end to start the negotiation about the capability that the TE
link can support.
One new Subobject named HO ODU Link Capability Subobject in the
DATA_LINK object is introduced by this document. This new subobect is
used to tell the remote end of the HO ODU link which are the TS
granularity and the LO ODU signal types that the local end can
support. When the DATA_LINK object carries the new HO ODU Link
Capability Subobject, the N flag SHOULD be set to 1 which means that
the subobject is negotiable.
5.1.2. LinkSummaryAck Message
The LinkSummaryAck message is used to tell the remote end that it has
the same capability as the remote end after the LinkSummary message
is received by the local end.
5.1.3. LinkSummaryNack Message
The LinkSummaryNack message is used to tell the remote end that it
has different capability from the remote end after the LinkSummary
message is received by the local end. The LinkSummaryNack message
also carries the HO ODU Link Capability Subobject in the DATA_LINK
object to tell the remote end the exact capability of the HO ODU link
after negotiation, i.e., the granularity of TS and the types of LO
ODU that both side of the HO ODU link can support.
Zhang Expires April 2010 [Page 8]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
5.2. Object Definitions
A new HO ODU Link Capability subobject type is introduced to the DATA
LINK object to carry the HO ODU link capability information. The
format of the new subobject is defined as follow:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |OD(T)Uk| T | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|C|D|E|F|G| LO ODU Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
The value of this subobject type is TBD.
Length (8 bits):
The Length field contains the total length of the subobject in bytes,
including the Type and Length fields. As for RFC 4204, the Length
MUST be at least 4, and MUST be a multiple of 4. Value of this field
is 8.
OD(T)Uk (4 bits):
This field is used to indicate the HO ODU link type (in case of LO
ODUj multiplexing into HO ODUk, wherein j<k) or the OTU link type (in
case of LO ODUk mapping into OTUk).
OD(T)Uk field Signal type of HO ODUk or OTUk
------------- ------------------------------
0 Reserved (for future use)
1 HO ODU1 or OTU1
2 HO ODU2 or OTU2
3 HO ODU3 or OTU3
4 HO ODU4 or OTU4
5 OTU2e
6 OTU3e1
7 OTU3e2
8-15 Reserved (for future use)
Zhang Expires April 2010 [Page 9]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
T (2 bits):
The T bits are used to indicate the granularity of the TS of the HO
ODU link.
T field TS type
------- -------
0 1.25Gbps TS granularity
1 2.5Gbps TS granularity
2-3 Reserved (for future use)
LO ODU flags (A|B|C|D|E|F|G) (16 bits):
These flags are used to indicate which LO ODU signal types that one
end or the both end can support. The flags will be set to 1 if the
corresponding LO ODU signal types are supported to be mapped or
multiplexed into the OTUk or HO ODUk link.
This rule imposes that:
- At least one flag is set to 1.
- When the ODUk flag corresponding to the signal type HO ODUk/OTUk
is set to 1, then the signal type has to be intended as LO ODUk
and direct mapping over OTUk is supported.
- When an ODUk flag not corresponding to the signal type HO
ODUk/OTUk is set to 1 then the signal type has to be intended as
HO ODUk and multiplexing of LO ODUj over HO ODUk is supported.
Flag A: indicates whether LO ODU0 is supported.
Flag B: indicates whether LO ODU1 is supported.
Flag C: indicates whether LO ODU2 is supported.
Flag D: indicates whether LO ODU3 is supported.
Flag E: indicates whether LO ODU4 is supported.
Flag F: indicates whether LO ODU2e is supported.
Flag G: indicates whether LO ODUflex is supported.
Zhang Expires April 2010 [Page 10]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
For example, if one end of an OTU2 link supports LO ODU0, LO ODU1, LO
ODUflex into HO ODU2 multiplexing and supports LO ODU2 into OTU2
mapping, the flags A, B, C, and G will be set to 1.
As a further example, if one end of an OTU2 link supports only LO
ODU2 into OTU2 mapping but no multiplexing, only flag C will be set
to 1.
The remaining flags are reserved for future use and MUST be set to 0.
5.3. Procedures
The Link Summary messages used for capability discovery for HO ODUk
or OTUk link are sent between adjacent nodes after the HO ODU link is
created or driven by some events (e.g., an operator command). The
procedure is described below:
o The local end of the HO ODU link sends a LinkSummary message
including one or more DATA_LINK objects, each of which contains
the Local_Interface_Id, the Remote_Interface_Id, and the HO ODU
link capability subobject. This subobject carries the capability
that the local end can support, i.e., the granularity of TS and
the set of LO ODU signal types that the local end can support. The
LinkSummary message is sent to the remote end.
o On receipt of the LinkSummary message, the remote end of the HO
ODU link firstly determines whether the local/remote Interface_Id
mappings match those that are stored locally as described in
[RFC4204], and then obtains the HO ODU link capability subobject
and determines the capability of the HO ODU link that both ends
can support. The detail procedures are as follow:
- Only if both ends support the 1.25Gbps TS, the remote end would
choose the 1.25Gbps as the negotiated granularity for the HO
ODU link. In other cases, the 2.5Gbps TS MUST be used (i.e., if
the local end can support 1.25Gbps, and the remote end can
support 2.5Gbps, and then the local end should imitate 2.5Gbps).
- The remote end compares the two sets of LO ODU signal types
that the local end and the remote end can support, and
calculates the intersection of them, i.e., extracts all the LO
ODU signal types that both two ends can support. This
intersection is the set of LO ODU signal types that the HO ODU
link can support.
o If both the two ends support the same capability, i.e., they
support the same granularity of TS and the same LO ODU signal
Zhang Expires April 2010 [Page 11]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
types, the remote end replies a LinkSummaryAck message to the
local end. So the both ends know what capability the HO ODU link
can support.
o If the two ends support different capabilities, i.e., they support
different granularities of TS or different LO ODU signal types,
the remote end replies a LinkSummaryNack message to the local end.
The LinkSummaryNack message carries an ERROR_CODE object and one
or more DATA_LINK objects. The ERROR_CODE object indicates that
the two ends of the HO ODU link support different capabilities,
and the DATA_LINK object carries the HO ODU link capability
subobject which contains the negotiated granularity of TS and the
set of LO ODU signal types that both ends can support. The local
end can learn the HO ODU link capability after receiving the
LinkSummaryNack message.
o If the remote end does not support the HO ODU link capability
negotiation procedure, the LinkSummaryNack message MUST be
responded with an ERROR_CODE indicating the reason of rejection.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgments
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation, March 2003.
Zhang Expires April 2010 [Page 12]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
[Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)",
December 2008.
[G709-V3] ITU-T, "Draft revised G.709, version 3", consented by
ITU-T on Oct 2009.
9.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, Jan 2006.
10. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972910
Email: danli@huawei.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Zhang Expires April 2010 [Page 13]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Guoying Zhang
China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie Beijing, P.R.China
Phone: +86-10-68094272
Email: zhangguoying@mail.ritt.com.cn
Pietro Grandi
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6864930
Email: pietro_vittorio.grandi@alcatel-lucent.it
Sergio Belotti
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6863033
Email: sergio.belotti@alcatel-lucent.it
Zhang Expires April 2010 [Page 14]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
11. Contributors
Yi Lin
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972914
Email: linyi_hw@huawei.com
Intellectual Property
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
Zhang Expires April 2010 [Page 15]
draft-zhang-ccamp-gmpls-g.709-lmp-discovery-02.txt October 2009
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhang Expires April 2010 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 12:21:46 |