diff options
Diffstat (limited to 'doc/rfc/rfc3475.txt')
| -rw-r--r-- | doc/rfc/rfc3475.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3475.txt b/doc/rfc/rfc3475.txt new file mode 100644 index 0000000..fde3151 --- /dev/null +++ b/doc/rfc/rfc3475.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group O. Aboul-Magd +Request for Comments: 3475 Nortel Networks +Category: Informational March 2003 + + + Documentation of IANA assignments for + Constraint-Based LSP setup using LDP (CR-LDP) Extensions + for Automatic Switched Optical Network (ASON) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + Automatic Switched Optical Network (ASON) is an architecture, + specified by ITU-T Study Group 15, for the introduction of a control + plane for optical networks. The ASON architecture specifies a set of + reference points that defines the relationship between the ASON + architectural entities. Signaling over interfaces defined in those + reference points can make use of protocols that are defined by the + IETF in the context of Generalized Multi-Protocol Label Switching + (GMPLS) work. This document describes Constraint-Based LSP setup + using LDP (CR-LDP) extensions for signaling over the interfaces + defined in the ASON reference points. The purpose of the document is + to request that the IANA assigns code points necessary for the CR-LDP + extensions. The protocol specifications for the use of the CR-LDP + extensions are found in ITU-T documents. + +Table of Contents + + 1. Introduction ................................................. 2 + 2. Overview of CR-LDP Extensions for ASON ....................... 2 + 3. CR-LDP Messages for ASON ..................................... 3 + 3.1 Call Setup Message ........................................ 4 + 3.1.2 Call Setup Procedure ................................. 5 + 3.2 The Call Release Message .................................. 5 + 3.2.1 Call Release Procedure ............................... 6 + 4. CR-LDP TLV for ASON .......................................... 6 + 4.1 Call ID TLV ............................................... 6 + 4.1.1 Call ID Procedure .................................... 8 + 4.2 Call Capability TLV ....................................... 9 + + + +Aboul-Magd Informational [Page 1] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + 4.3 Crankback TLV ............................................. 9 + 5. Additional Error Codes ....................................... 10 + 6. IANA Consideration ........................................... 11 + 9. Security Considerations ...................................... 11 + 10. Normative References ......................................... 11 + 11. Intellectual Property ........................................ 12 + 12. Author's Address ............................................. 12 + 13. Full Copyright Statement ..................................... 13 + +1. Introduction + + Automatic Switched Optical Network (ASON) is an architecture, + specified by ITU-T Study Group 15 (SG15), for the introduction of a + control plane for optical networks. The development and the + standardization of ASON has been done by ITU-T SG15 and is documented + in recommendation G.8080 [1]. The architecture includes a control + plane with a set of reference points between the architectural + components. The ASON signaling that runs over interfaces defined in + those reference points are described in ITU-T recommendation G.7713 + [2]. + + Constraint-Based LSP Setup using LDP (CR-LDP) [3] is one of the + protocols selected by the ITU for the realization of G.7713 and its + dynamic connection management. The work specific to CR-LDP extensions + for ASON is documented in ITU-T recommendation G.7713.3 [8]. + + This document introduces those CR-LDP extensions that are specific to + ASON and requests IANA allocation of code points for these + extensions. The document does not specify how these extensions are + used; that is the subject of the above mentioned ITU-T documents. + This document should be considered in conjunction with RFC 3036 [4], + RFC 3212 [3], and CR-LDP extensions for GMPLS [5]. + +2. Overview of CR-LDP Extensions for ASON + + This document describes ASON specific CR-LDP extensions covering the + following ASON signaling requirements: + + - Call and connection control separation + - Support of Soft Permanent Connections (SPC) + - Crankback + - Additional error codes + + An important ASON architectural principle is the separation between + the call and the connection controllers as described in G.8080. Call + and connection control separation allows for a call with multiple + connections associated with it. It also allows for a call with no + + + + +Aboul-Magd Informational [Page 2] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + connections (a temporary situation that might be useful during + recovery). + + The separation of the call and the connection controllers could be + achieved using one of two models. The first model is one where the + call set up request is always accompanied by a connection request. + The second model is one in which call set up is done independently + from connection set up. The first model is usually referred to as + logical separation, while the second model is usually referred to as + complete separation. CR-LDP extensions for ASON support the two + separation models. + + Two new messages are introduced for call operations (set up and + release). The Call Setup message is used for those cases where + complete separation is required. Otherwise the LDP Label Request + message is used for logical separation. + + A connection set up request must indicate the call to which the + connection needs to be associated. A Call ID TLV is introduced to + achieve this goal. The structure of the Call ID allows it to have a + global or an operator scope. + + Call release is always achieved using the Call Release message. The + reception of the call Release messages signifies the intention to + remove all connections that are associated to the call. Connection + release is achieved using the CR-LDP label release procedure (using + LDP Label Release and Label Withdraw messages) as defined in [4]. + + A Call Capability TLV is also introduced to explicitly indicate the + capability of the requested call. + + An Soft Permanent Connection (SPC) service assumes that both source + and destination user-to-network connection segments are provisioned + while the network connection segment is set up via the control plane. + For example when the initial request is received from an external + source, e.g. from a management system, there is an implicit + assumption that the control plane has adequate information to + determine the specific destination (network-to-user) link connection + to use. Support for CR-LDP is provided by the use of the Egress + Label TLV as defined in the OIF UNI 1.0 section 11.7.5 [6] from the + Optical Internetworking Forum and in RFC3476 [7]. + +3. CR-LDP Messages for ASON + + This section describes the formats and the procedures of the two + messages that are required for ASON call and connection control + separation. Those messages are the Call Setup messages and the Call + Release message. + + + +Aboul-Magd Informational [Page 3] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + +3.1 Call Setup Message + + The format of the Call Setup message is: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0| Call Setup (0x0500) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dest ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Capability TLV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Parameters | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Message ID: + Is as defined in RFC3036 [4]. + + Source ID TLV: + Is as defined in UNI 1.0 [6] and in [7]. + + Dest ID TLV: + Is as defined in UNI 1.0 [6] and in [7]. + + Call ID TLV: + Is as defined in section 4.1 of this document. + + Call Capability TLV: + Is as defined in section 4.2 of this document. + + + + + + + + +Aboul-Magd Informational [Page 4] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + +3.1.2 Call Setup Procedure + + The Calling party sends the Call Setup message whenever a new call + needs to be set up with no connection associated with it. The Call + Setup message shall contain all the information required by the + network to process the call. In particular, the Call Setup message + shall include the calling and called party addresses as specified by + the Source ID and Dest ID TLV. The setup message must include Call + ID TLV. The call control entity shall identify the call using the + selected identifier for the lifetime of the call. The Call Setup + message shall progress through the network to the called party. The + called party may accept or reject the incoming call. An LDP + Notification message with the appropriate status code shall be used + to inform the calling party whether the setup is successful. The + call can be rejected by either the network, e.g. for policy reasons, + or by the called party. + +3.2 The Call Release Message + + This format of the Call Release message is: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0| Call Release (0x0501) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dest ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID TLV | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Parameters | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Aboul-Magd Informational [Page 5] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + +3.2.1 Call Release Procedure + + The Call Release message is sent by any entity of the network to + terminate an already established call. The Call Release message must + include the Call ID TLV of the call to be terminated. Confirmation + of call release is indicated to the request initiator using a + Notification message with the appropriate status code. Reception and + processing of the Call Release message must trigger the release of + all connections that are associated with that call. Connection + release follows the normal CR-LDP procedure using Label Release and + Label Withdraw messages. + +4. CR-LDP TLVs for ASON + + This section describes the operator specific Call ID TLV, the + globally unique Call ID TLV, the Call Capability TLV and the + Crankback TLV introduced for ASON. + +4.1 Call ID TLV + + An established call may be identified by a Call ID. The Call ID is a + globally unique identifier that is set by the source network. The + structure for the Call ID (to guarantee global uniqueness) is to + concatenate a globally unique fixed identifier (composed of country + code, carrier code, unique access point code) with an operator + specific identifier (where the operator specific identifier is + composed of ingress network element (NE) address and a local + Identifier). + + Therefore, a generic CALL_ID with global uniqueness includes <global + Id> (composed of <country code> plus <carrier code> plus <unique + access point code>) and <operator specific Id> (composed of <NE + address> plus <local Identifier>). For a CALL_ID that requires only + operator specific uniqueness, only the <operator specific Id> is + needed, while for a CALL_ID that is required to be globally unique + both <global ID> and <operator specific Id> are needed. + + The <global Id> shall consist of a three-character International + Segment (the <country code>) and a twelve-character National Segment + (the <carrier code> plus <unique access point code>). These + characters shall be coded according to ITU-T Recommendation T.50. + + + + + + + + + + +Aboul-Magd Informational [Page 6] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + The format of the operator specific (Op-Sp) CALL_ID TLV: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F|Op-Sp Call ID (0x0831) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NE Address (NEA Sub TLV) | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Identifier (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + NEA Sub TLV: + The Source NE Address is an address of the transport network + element controlled by the source network. Its length can be 4, 6, + 16, or 20 bytes long. The NEA Sub TLV is TLV Type 1. + + Local Identifier: + A 64-bit identifier that remains constant over the life of the + call. + + The format of the globally unique (GU) Call ID TLV: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F|GU Call ID (0x0832) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | IS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NS | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NE Address (NEA Sub TLV) | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Identifier (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Aboul-Magd Informational [Page 7] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + + International Segment (IS): + To be coded according to ITU-T recommendation T.50. The + International Segment (IS) field provides a 3 character ISO 3166 + Geographic/Political Country Code. The country code is based on + the three-character uppercase alphabetic ISO 3166 Country Code + (e.g., USA, FRA). + + National Segment (NS): + The National Segment (NS) field consists of two sub-fields: + + - the first subfield contains the ITU Carrier Code + - the second subfield contains a Unique Access Point Code. + + The ITU Carrier Code is a code assigned to a network + operator/service provider, maintained by the ITU-T + Telecommunication Service Bureauin association with Recommendation + M.1400. This code consists of 1-6 left-justified alphabetic, or + leading alphabetic followed by numeric, characters (bytes). If + the code is less than 6 characters (bytes), it is padded with a + trailing NULL to fill the subfield. + + The Unique Access Point Code is a matter for the organization to + which the country code and ITU carrier code have been assigned, + provided that uniqueness is guaranteed. This code consists of 1-6 + characters (bytes), trailing NULL, completing the 12-character + National Segment. If the code is less than 6 characters, it is + padded by a trailing NULL to fill the subfield. + + Format of the National Segment + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ITU carrier code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ITU carrie dode (cont) | Unique access point code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unique access point code (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.1 Call ID Procedure + + The following processing rules are applicable to the CALL ID TLV: + + - For initial calls, the calling/originating party call controller + must set the CALL ID values to all-zeros. + + + + +Aboul-Magd Informational [Page 8] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + - For a new call request, the source networks call controller (SNCC) + sets the appropriate type and value for the CALL ID. + - For an existing call (in case Call ID is non zero) the SNCC + verifies existence of the call. + - Intermediate nodes are not allowed to alter the Call ID TLV set by + the ingress node. + - The destination user/client receiving the request uses the CALL ID + values as a reference to the requested call between the source + user and itself. Subsequent actions related to the call uses the + CALL ID as the reference identifier. + +4.2 Call Capability TLV + + The format of the Call Capability TLV is: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| Call Capabaility(0x0833) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Call Capability TLV contains a 4 byte Call Capability field. The + Call Capability Field is used to explicitly indicate the + configuration potentiality of the call. + + An example of values of the Call Capability field is: + + 0x0000 Point to Point call + +4.3 Crankback TLV + + Crankback requires that when the Label Request message is blocked at + a particular node due to unavailable resources, the node will inform + the initiator of the Label Request message of the location of the + blockage. The initiator can then re-compute new explicit routes that + avoid the area where resource shortage is detected. A new Label + Request message is sent that includes the new route. + + The support of crankback in CR-LDP is facilitated by the introduction + of a Crankback TLV. An LDP Notification message is used to inform + the Label Request message initiator of the blocking condition. The + Notification message includes the Crankback TLV that indicates the + location of resource shortage. The location of the resource shortage + is identified using the ER-HOP TLV. The encoding of the Crankback + TLV is: + + + +Aboul-Magd Informational [Page 9] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| Crankback(0x0834) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ER-HOP TLV ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The ER-HOP TLV is specified in rfc3212 [3], and consists of an n x 4 + bytes field, it could e.g. contain an IPv4 or an IPv6 address. + +5. Additional Error Codes + + G.7713 includes a number of error codes that are currently not + defined in earlier CR-LDP related RFCs. The list of those error + conditions is given below: + + Invalid SNP ID (0x04000009) + Calling Party busy (0x0400000a) + Unavailable SNP ID (0x0400000b) + Invalid SNPP ID (0x0400000c) + Unavailable SNPP ID (0x0400000d) + + Failed to create SNC (0x0400000e) + Failed to establish LC (0x040000f) + Invalid Source End-User Name (0x04000010) + Invalid Destination End-User Name (0x04000011) + Invalid CoS (0x04000012) + Unavailable CoS (0x04000013) + Invalid GoS (0x04000014) + Unavailable GoS (0x04000015) + Failed Security Check (0x04000016) + TimeOut (0x04000017) + Invalid Call Name (0x04000018) + Failed to Release SNC (0x04000019) + Failed to Free LC (0x0400001a) + + Acronyms used in above error codes: + + SNP Sub-network Point + SNPP Sub-network Point Pool + SNC Sub-network Connection + LC Link Connection + CoS Class of Service + GoS Grade of Service + + + + + +Aboul-Magd Informational [Page 10] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + +6. IANA Consideration + + This document uses the LDP RFC 3036 [4] name spaces; see + http://www.iana.org/assignments/ldp-namespaces. + + Call Setup (0x0500) + Call Release (0x0501) + + The assignment for the following TLVs: + + Op-Sp Call ID TLV (0x0831) + GU Call ID TLV (0x0832) + Call Capability TLV (0x0833) + Crankback TLV (0x0834) + + The assignment for the new error codes as listed in section 5 of this + document. + +9. Security Considerations + + This document does not introduce any new security concerns other than + those defined in RFC 3036 and RFC 3212. + + Security aspects (if any) w.r.t. the G.8080 and G.7713 documents need + to be addressed in those documents. + +10. Normative References + + [1] Architecture for Automatically Switched Optical Network (ASON), + ITU-T recommendation G.8080, Nov. 2001 + + [2] Distributed Call and Connection Management (DCM), ITU-T + recommendation G.7713, Dec. 2001 + + [3] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., + Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., + Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based + LSP Setup using LDP", RFC 3212, January 2002. + + [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. + Thomas, "LDP Specifications", RFC 3036, January 2001. + + [5] Ashwood-Smith, P. and L. Berger, (Editors),"Generalized Multi- + Protocol Label Switching (GMPLS) Signaling Constraint-based + Routed Label Distribution Protocol (CR-LDP) Extensions", RFC + 3472, January 2003. + + + + + +Aboul-Magd Informational [Page 11] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + + [6] UNI 1.0 Signaling Specification, The Optical Internetworking + Forum, http://www.oiforum.com/public/UNI_1.0_ia.html + + [7] Rajagopalan, B., "Label Distribution Protocol (LDP) and Resource + ReserVation Protocol (RSVP) Extensions for Optical UNI + Signaling", RFC 3476, March 2003. + + [8] Distributed Call and Connection Management signalling using GMPLS + CR-LDP, ITU G.7713.3, Januray 2003. + +11. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in RFC 2028. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +12. Author's Addresses + + Osama Aboul-Magd + Nortel Networks + P.O. Box 3511, Station C + Ottawa, Ontario, Canada + K1Y 4H7 + Phone: 613-599-9104 + EMail: osama@nortelnetworks.com + + + + + + + + + + +Aboul-Magd Informational [Page 12] + +RFC 3475 CR-LDP Extensions for ASON March 2003 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Aboul-Magd Informational [Page 13] + |