idnits 2.17.1
draft-ietf-mpls-bundle-06.txt:
** The Abstract section seems to be numbered
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 19.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 479.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 490.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 497.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 503.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC3471]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
-- The draft header indicates that this document updates RFC3471, but the
abstract doesn't seem to directly say this. It does mention RFC3471
though, so this could be OK.
-- The draft header indicates that this document updates RFC3472, but the
abstract doesn't seem to mention this, which it should.
-- The draft header indicates that this document updates RFC3473, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
If one of the component links goes down, the associated bundled
link remains up and continues to be advertised, provided that at least
one component link associated with the bundled link is up. The
unreserved bandwidth of the component link that is down is set to zero,
and the unreserved bandwidth and maximum LSP bandwidth of the bundle must
be recomputed. If all the component links associated with a given bundled
link are down, the bundled link MUST not be advertised into OSPF/IS-IS.
(Using the creation date from RFC3471, updated by this document, for
RFC5378 checks: 2000-10-23)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 2004) is 7072 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'BUNDLE' is mentioned on line 389, but not defined
== Unused Reference: 'RFC3480' is defined on line 427, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational draft:
draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS')
** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305)
Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Kireeti Kompella
2 Updates: 3471, 3472, 3473 Juniper Networks
3 Category: Standards Track Yakov Rekhter
4 Expiration Date: June 2005 Juniper Networks
5 Lou Berger
6 Movaz Networks
8 December 2004
10 Link Bundling in MPLS Traffic Engineering
12 draft-ietf-mpls-bundle-06.txt
14 1. Status of this Memo
16 By submitting this Internet-Draft, I certify that any applicable
17 patent or other IPR claims of which I am aware have been disclosed,
18 or will be disclosed, and any of which I become aware will be
19 disclosed, in accordance with RFC 3668.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than a "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/1id-abstracts.html
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html
37 2. Abstract
39 For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
40 signaling in certain cases a combination of
41 is not sufficient to unambiguously identify the appropriate resource
42 used by a Label Switched Path (LSP). Such cases are handled by using
43 the link bundling construct which is described in this document.
44 This document updates the interface identification TLVs defined in
45 GMPLS Signaling Functional Description, [RFC3471].
47 Contents
49 1 Status of this Memo ....................................... 1
50 2 Abstract .................................................. 1
51 3 Specification of Requirements ............................. 3
52 4 Link Bundling ............................................. 3
53 4.1 Restrictions on Bundling .................................. 4
54 4.2 Routing Considerations .................................... 4
55 4.3 Signaling Considerations .................................. 5
56 4.3.1 Interface Identification TLV Format ....................... 6
57 4.3.2 Errored Component Identification .......................... 6
58 5 Traffic Engineering Parameters for Bundled Links .......... 7
59 5.1 OSPF Link Type ............................................ 7
60 5.2 OSPF Link ID .............................................. 7
61 5.3 Local and Remote Interface IP Address ..................... 7
62 5.4 Local and Remote Identifiers .............................. 7
63 5.5 Traffic Engineering Metric ................................ 8
64 5.6 Maximum Bandwidth ......................................... 8
65 5.7 Maximum Reservable Bandwidth .............................. 8
66 5.8 Unreserved Bandwidth ...................................... 8
67 5.9 Resource Classes (Administrative Groups) .................. 8
68 5.10 Maximum LSP Bandwidth ..................................... 8
69 6 Bandwidth Accounting ...................................... 9
70 7 Security Considerations ................................... 9
71 8 IANA Considerations ....................................... 9
72 9 References ................................................ 10
73 9.1 Normative References ...................................... 10
74 9.2 Non-normative References .................................. 11
75 10 Author Information ........................................ 11
76 11 Full Copyright Statement .................................. 11
77 12 Intellectual Property ..................................... 12
78 3. Specification of Requirements
80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
82 document are to be interpreted as described in RFC 2119 [RFC2119].
84 4. Link Bundling
86 As defined in [GMPLS-ROUTING], a TE link is a logical construct that
87 represents a way to group/map the information about certain physical
88 resources (and their properties) that interconnect LSRs into the
89 information that is used by Constrained SPF for the purpose of path
90 computation, and by GMPLS signaling.
92 As further stated in [GMPLS-ROUTING], depending on the nature of
93 resources that form a particular TE link, for the purpose of GMPLS
94 signaling in some cases a combination of
95 is sufficient to unambiguously identify the appropriate resource used
96 by an LSP. In other cases, a combination of is not sufficient. Such cases are handled by using the link
98 bundling construct which is described in this document.
100 Consider a TE link such that for the purpose of GMPLS signaling a
101 combination of is not sufficient to
102 unambiguously identify the appropriate resources used by an LSP. In
103 this situation the link bundling construct assumes that the set of
104 resources that form the TE link could be partitioned into disjoint
105 subsets, such that (a) the partition is minimal, and (b) within each
106 subset a label is sufficient to unambiguously identify the
107 appropriate resources used by an LSP. We refer to such subsets as
108 "component links", and to the whole TE link as a "bundled link".
109 Furthermore we restrict the identifiers that can be used to identify
110 component links such that they are unique for a given node. On a
111 bundled link a combination of is
112 sufficient to unambiguously identify the appropriate resources used
113 by an LSP.
115 The partition of resources that form a bundled link into component
116 links has to be done consistently at both ends of the bundled link.
117 Both ends of the bundled link also have to understand each others
118 component link identifiers.
120 The purpose of link bundling is to improve routing scalability by
121 reducing the amount of information that has to be handled by OSPF
122 and/or IS-IS. This reduction is accomplished by performing
123 information aggregation/abstraction. As with any other information
124 aggregation/abstraction, this results in losing some of the
125 information. To limit the amount of losses one need to restrict the
126 type of the information that can be aggregated/abstracted.
128 4.1. Restrictions on Bundling
130 All component links in a bundle must begin and end on the same pair
131 of LSRs, have the same Link Type (i.e., point-to-point or
132 multi-access), the same Traffic Engineering metric, and the same set
133 of resource classes at each end of the links.
135 A Forwarding Adjacency may be a component link; in fact, a bundle can
136 consist of a mix of point-to-point links and FAs.
138 If the component links are all multi-access links, the set of IS-IS
139 or OSPF routers connected to each component link must be the same,
140 and the Designated Router for each component link must be the same.
141 If these conditions cannot be enforced, multi-access links must not
142 be bundled.
144 Component link identifiers MUST be unique across both TE and
145 component link identifiers on a particular node. This means that
146 unnumbered identifiers have node wide scope, and that numbered
147 identifiers have the same scope as IP addresses.
149 4.2. Routing Considerations
151 A component link may be either numbered or unnumbered. A bundled link
152 may itself be numbered or unnumbered independent of whether the
153 component links of that bundled link are numbered or not.
155 Handling identifiers for unnumbered component links, including the
156 case where a link is formed by a Forwarding Adjacency, follows the
157 same rules as for an unnumbered TE link (see Section "Link
158 Identifiers" of [RFC3477]/[RFC3480]). Furthermore, link local
159 identifiers for all unnumbered links of a given LSR (whether
160 component links, Forwarding Adjacencies or bundled links) MUST be
161 unique in the context of that LSR.
163 The "liveness" of the bundled link is determined by the liveness of
164 each of the component links within the bundled link - a bundled link
165 is alive when at least one its component links is determined to be
166 alive. The liveness of a component link can be determined by any of
167 several means: IS-IS or OSPF hellos over the component link, or RSVP
168 Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2
169 indications.
171 Once a bundled link is determined to be alive, it can be advertised
172 as a TE link and the TE information can be flooded. If IS-IS/OSPF
173 hellos are run over the component links, IS-IS/OSPF flooding can be
174 restricted to just one of the component links. Procedures for doing
175 this are outside the scope of this document.
177 In the future, as new Traffic Engineering parameters are added to
178 IS-IS and OSPF, they should be accompanied by descriptions as to how
179 they can be bundled, and possible restrictions on bundling.
181 4.3. Signaling Considerations
183 Typically, an LSP's ERO will identify the bundled link to be used for
184 the LSP, but not the component link, since information about the
185 bundled link is flooded, but information about the component links is
186 not. The identification of a component link in an ERO is outside the
187 scope of this document. When the bundled link is identified in an
188 ERO or is dynamically identified, the choice of the component link
189 for the LSP is a local matter between the two LSRs at each end of the
190 bundled link.
192 Signaling must identify both the component link to use and the label
193 to use. The choice of the component link to use is always made by the
194 sender of the Path/REQUEST message (if an LSP is bidirectional
195 [RFC3471], the sender chooses a component link in each direction).
196 The handling of labels is not modified by this document.
198 Component link identifiers are carried in RSVP messages as described
199 in section 8 of [RFC3473]. Component link identifiers are carried in
200 CR-LDP messages as described in section 8 of [RFC3473]. Additional
201 processing related to unnumbered links is described in the
202 "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" and
203 "Unnumbered Forwarding Adjacencies" sections of [RFC3477]/[RFC3480].
205 [RFC3471] defines the Interface Identification TLV types. This
206 document specifies that the TLV types 1, 2 and 3 SHOULD be used to
207 indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
208 Type 1 TLVs are used for IPv4 numbered component link identifiers.
209 Type 2 TLVs are used for IPv6 numbered component link identifiers.
210 Type 3 TLVs are used for unnumbered component link identifiers. The
211 Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
212 Note, in Path and REQUEST messages, link identifiers MUST be
213 specified from the sender's perspective.
215 Except in the special case noted below, for a unidirectional LSP,
216 only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
217 TLV. This TLV indicates the component link identifier of the
218 downstream data channel on which label allocation must be done.
220 Except in the special case noted below, for a bidirectional LSP, only
221 one or two TLVs SHOULD used in an IF_ID RSVP_HOP object or IF_ID TLV.
222 The first TLV always indicates the component link identifier of the
223 downstream data channel on which label allocation must be done. When
224 present, the second TLV always indicates the component link
225 identifier of the upstream data channel on which label allocation
226 must be done. When only one TLV is present, it indicates the
227 component link identifier for both downstream and upstream data
228 channels.
230 In the special case where the same label is to be valid across all
231 component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or
232 IF_ID TLV. The first TLV indicates the TE link identifier of the
233 bundle on which label allocation must be done. The second TLV
234 indicates a bundle scope label. For TLV types 1 and 2 this is done
235 by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for
236 a type 1 TLV. Per [RFC3471], for TLV types 3, 4 and 5, this is done
237 by setting the Interface ID field to the special value 0xFFFFFFFF.
238 Note that this special case applies to both unidirectional and
239 bidirectional LSPs.
241 Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
242 the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
244 4.3.1. Interface Identification TLV Format
246 This section modifies section 9.1.1. of [RFC3471]. The definition of
247 the IP Address field of the TLV types 3, 4 and 5 is clarified.
249 For types 3, 4 and 5 the Value field has the identical format as
250 the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
251 defined in [RFC3477]. Note this results in the renaming of the IP
252 Address field defined in [RFC3471].
254 4.3.2. Errored Component Identification
256 When Interface Identification TLVs are used, the TLVs are also used
257 to indicate the specific components associated with an error. For
258 RSVP, this means that any received TLVs SHOULD be copied into the
259 IF_ID ERROR_SPEC object, see Section 8.2 in [RFC3473]. The Error
260 Node Address field of the object SHOULD indicate the TE Link
261 associated with the error. For CR-LDP, this means that any received
262 TLVs SHOULD be copied into the IF_ID Status TLV, see Section 8.2 in
263 [RFC3472]. The HOP Address field of the TLV SHOULD indicate the TE
264 Link associated with the error.
266 5. Traffic Engineering Parameters for Bundled Links
268 In this section, we define the Traffic Engineering parameters to be
269 advertised for a bundled link, based on the configuration of the
270 component links and of the bundled link. The definition of these
271 parameters for component links was undertaken in [RFC3784] and
272 [RFC3630]; we use the terminology from [RFC3630].
274 5.1. OSPF Link Type
276 The Link Type of a bundled link is the (unique) Link Type of the
277 component links. (Note: this parameter is not present in IS-IS.)
279 5.2. OSPF Link ID
281 For point-to-point links, the Link ID of a bundled link is the
282 (unique) Router ID of the neighbor. For multi-access links, this is
283 the interface address of the (unique) Designated Router. (Note: this
284 parameter is not present in IS-IS.)
286 5.3. Local and Remote Interface IP Address
288 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4
289 Neighbor Address, respectively.)
291 If the bundled link is numbered, the Local Interface IP Address is
292 the local address of the bundled link; similarly, the Remote
293 Interface IP Address is the remote address of the bundled link.
295 5.4. Local and Remote Identifiers
297 If the bundled link is unnumbered, the link local identifier is set
298 to the identifier chosen for the bundle by the advertising LSR. The
299 link remote identifier is set to the identifier chosen by the
300 neighboring LSR for the reverse link corresponding to this bundle, if
301 known; otherwise, this is set to 0.
303 5.5. Traffic Engineering Metric
305 The Traffic Engineering Metric for a bundled link is that of the
306 component links.
308 5.6. Maximum Bandwidth
310 This parameter is not used. The maximum LSP Bandwidth (as described
311 below) replaces the Maximum Bandwidth for bundled links.
313 5.7. Maximum Reservable Bandwidth
315 We assume that for a given bundled link either each of its component
316 links is configured with the Maximum Reservable Bandwidth, or the
317 bundled link is configured with the Maximum Reservable Bandwidth. In
318 the former case, the Maximum Reservable Bandwidth of the bundled link
319 is set to the sum of the Maximum Reservable Bandwidths of all
320 component links associated with the bundled link.
322 5.8. Unreserved Bandwidth
324 The unreserved bandwidth of a bundled link at priority p is the sum
325 of the unreserved bandwidths at priority p of all the component links
326 associated with the bundled link.
328 5.9. Resource Classes (Administrative Groups)
330 The Resource Classes for a bundled link are the same as those of the
331 component links.
333 5.10. Maximum LSP Bandwidth
335 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
336 For an unbundled link the Maximum Bandwidth is defined in
337 [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at
338 priority p is defined to be the maximum of the Maximum LSP Bandwidth
339 at priority p of all of its component links.
341 The details of how Maximum LSP Bandwidth is carried in IS-IS is given
342 in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried
343 in OSPF is given in [GMPLS-OSPF].
345 6. Bandwidth Accounting
347 The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
348 LSR with bundled links must apply admission control on a
349 per-component link basis. An LSP with a bandwidth requirement b and
350 setup priority p fits in a bundled link if at least one component
351 link has maximum LSP bandwidth >= b at priority p. If there are
352 several such links, the choice of which link is used for the LSP is
353 up to the implementation.
355 In order to know the maximum LSP bandwidth (per priority) of each
356 component link, the Traffic Control module must track the unreserved
357 bandwidth (per priority) for each component link.
359 A change in the unreserved bandwidth of a component link results in a
360 change in the unreserved bandwidth of the bundled link. It also
361 potentially results in a change in the maximum LSP bandwidth of the
362 bundle; thus, the maximum LSP bandwidth should be recomputed.
364 If one of the component links goes down, the associated bundled link
365 remains up and continues to be advertised, provided that at least one
366 component link associated with the bundled link is up. The
367 unreserved bandwidth of the component link that is down is set to
368 zero, and the unreserved bandwidth and maximum LSP bandwidth of the
369 bundle must be recomputed. If all the component links associated with
370 a given bundled link are down, the bundled link MUST not be
371 advertised into OSPF/IS-IS.
373 7. Security Considerations
375 This document defines ways of utilizing procedures defined in other
376 documents referenced herein. Any security issues related to those
377 procedures are addressed in the referenced drafts. This document
378 thus raises no new security issues for RSVP-TE [RFC3209] or CR-LDP
379 [RFC3212].
381 8. IANA Considerations
383 This document changes the recommended usage of two of the
384 Interface_ID Types defined in [RFC3471]. For this reason, the IANA
385 registry of GMPLS Signaling Parameters should be updated for those
386 types to read:
388 4 12 See below COMPONENT_IF_DOWNSTREAM - Deprecated [BUNDLE]
389 5 12 See below COMPONENT_IF_UPSTREAM - Deprecated [BUNDLE]
391 9. References
393 9.1. Normative References
395 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
396 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
397 extensions-19.txt (work in progress)
399 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
400 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-
401 gmpls-extensions-12.txt (work in progress)
403 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al,
404 "Routing Extensions in Support of Generalized MPLS", draft-ietf-
405 ccamp-gmpls-routing-09.txt (work in progress)
407 [RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label
408 Switching (GMPLS) Signaling Functional Description", RFC 3471,
409 January 2003.
411 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
412 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
413 Engineering (RSVP-TE) Extensions.", RFC 3473, January 2003.
415 [RFC3472] Ashwood, P., Berger, L., et al., "Generalized Multi-
416 Protocol Label Switching (GMPLS) Signaling Constraint-based Routed
417 Label Distribution Protocol (CR-LDP) Extensions.", RFC 3472,January
418 2003.
420 [RFC3784] Smit, H., Li, T., "Intermediate System to Intermediate
421 System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
422 June 2004.
424 [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Engineering
425 (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
427 [RFC3480] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
428 Unnumbered Links in CR-LDP", RFC 3480, February 2003.
430 [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in
431 RSVP-TE", RFC 3477, January 2003.
433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
434 Requirement Levels", BCP 14, RFC 2119, March 1997.
436 [RFC3209] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
437 V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
438 RFC3209, December 2001
440 [RFC3212] Jamoussi, B., editor, "Constraint-Based LSP Setup using
441 LDP", RFC3212, December 2001
443 9.2. Non-normative References
445 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
446 draft-ietf-ccamp-lmp-10.txt (work in progress)
448 10. Author Information
450 Kireeti Kompella
451 Juniper Networks, Inc.
452 1194 N. Mathilda Ave.
453 Sunnyvale, CA 94089
454 Email: kireeti@juniper.net
456 Yakov Rekhter
457 Juniper Networks, Inc.
458 1194 N. Mathilda Ave.
459 Sunnyvale, CA 94089
460 Email: yakov@juniper.net
462 Lou Berger
463 Movaz Networks, Inc.
464 Voice: +1 703-847-1801
465 Email: lberger@movaz.com
467 11. Full Copyright Statement
469 Copyright (C) The Internet Society (2004). This document is subject
470 to the rights, licenses and restrictions contained in BCP 78, and
471 except as set forth therein, the authors retain all their rights.
473 This document and the information contained herein are provided on an
474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
476 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
477 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
478 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
481 12. Intellectual Property
483 The IETF takes no position regarding the validity or scope of any
484 Intellectual Property Rights or other rights that might be claimed to
485 pertain to the implementation or use of the technology described in
486 this document or the extent to which any license under such rights
487 might or might not be available; nor does it represent that it has
488 made any independent effort to identify any such rights. Information
489 on the procedures with respect to rights in RFC documents can be
490 found in BCP 78 and BCP 79.
492 Copies of IPR disclosures made to the IETF Secretariat and any
493 assurances of licenses to be made available, or the result of an
494 attempt made to obtain a general license or permission for the use of
495 such proprietary rights by implementers or users of this
496 specification can be obtained from the IETF on-line IPR repository at
497 http://www.ietf.org/ipr.
499 The IETF invites any interested party to bring to its attention any
500 copyrights, patents or patent applications, or other proprietary
501 rights that may cover technology that may be required to implement
502 this standard. Please address the information to the IETF at ietf-
503 ipr@ietf.org.
505 Generated on: Mon Dec 20 11:40:16 2004