RFC 4428 - Analysis of Generalized Multi-Protocol Label Swit(5)

时间:2006-11-02 来源: 作者: 点击:
operations.Per-componentfloodingofSRLGidentifierswoulddeeply impactthescalabilityofthelinkstateroutingprotocol. Therefore,onemayrelyontheusageofanon-lineaccessiblenetwork managementsystem. 9.Summarya
  
   operations.  Per-component flooding of SRLG identifiers would deeply
   impact the scalability of the link state routing protocol.
   Therefore, one may rely on the usage of an on-line accessible network
   management system.

9.  Summary and Conclusions

   The following table summarizes the different recovery types and
   schemes analyzed throughout this document.

   --------------------------------------------------------------------
              |       Path Search (computation and selection)
   --------------------------------------------------------------------
              |       Pre-planned (a)      |         Dynamic (b)
   --------------------------------------------------------------------
          |   | faster recovery            | Does not apply
          |   | less flexible              |
          | 1 | less robust                |
          |   | most resource-consuming    |
   Path   |   |                            |
   Setup   ------------------------------------------------------------
          |   | relatively fast recovery   | Does not apply
          |   | relatively flexible        |
          | 2 | relatively robust          |
          |   | resource consumption       |
          |   |  depends on sharing degree |
           ------------------------------------------------------------
          |   | relatively fast recovery   | less faster (computation)
          |   | more flexible              | most flexible
          | 3 | relatively robust          | most robust
          |   | less resource-consuming    | least resource-consuming
          |   |  depends on sharing degree |
   --------------------------------------------------------------------

   1a. Recovery LSP setup (before failure occurrence) with resource
       reservation (i.e., signaling) and selection is referred to as LSP
       protection.

   2a. Recovery LSP setup (before failure occurrence) with resource
       reservation (i.e., signaling) and with resource pre-selection is
       referred to as pre-planned LSP re-routing with resource pre-
       selection.  This implies only recovery LSP activation after
       failure occurrence.

   3a. Recovery LSP setup (before failure occurrence) with resource
       reservation (i.e., signaling) and without resource selection is
       referred to as pre-planned LSP re-routing without resource pre-
       selection.  This implies recovery LSP activation and resource
       (i.e., label) selection after failure occurrence.

   3b. Recovery LSP setup after failure occurrence is referred to as to
       as LSP re-routing, which is full when recovery LSP path
       computation occurs after failure occurrence.

   Thus, the term pre-planned refers to recovery LSP path pre-
   computation, signaling (reservation), and a priori resource selection
   (optional), but not cross-connection.  Also, the shared-mesh recovery
   scheme can be viewed as a particular case of 2a) and 3a), using the
   additional constraint described in Section 8.4.3.

   The implementation of these recovery mechanisms requires only
   considering extensions to GMPLS signaling protocols (i.e., [RFC3471]
   and [RFC3473]).  These GMPLS signaling extensions should mainly focus
   in delivering (1) recovery LSP pre-provisioning for the cases 1a, 2a,
   and 3a, (2) LSP failure notification, (3) recovery LSP switching
   action(s), and (4) reversion mechanisms.

   Moreover, the present analysis (see Section 8) shows that no GMPLS
   routing extensions are expected to efficiently implement any of these
   recovery types and schemes.

10.  Security Considerations

   This document does not introduce any additional security issue or
   imply any specific security consideration from [RFC3945] to the
   current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-
   TE) or network management protocols.

   However, the authorization of requests for resources by GMPLS-capable
   nodes should determine whether a given party, presumably already
   authenticated, has a right to access the requested resources.  This
   determination is typically a matter of local policy control, for
   example, by setting limits on the total bandwidth made available to
   some party in the presence of resource contention.  Such policies may
   become quite complex as the number of users, types of resources, and
   sophistication of authorization rules increases.  This is
   particularly the case for recovery schemes that assume pre-planned
   sharing of recovery resources, or contention for resources in case of
   dynamic re-routing.

   Therefore, control elements should match the requests against the
   local authorization policy.  These control elements must be capable
   of making decisions based on the identity of the requester, as
   verified cryptographically and/or topologically.

11.  Acknowledgements

   The authors would like to thank Fabrice Poppe (Alcatel) and Bart
   Rousseau (Alcatel) for their revision effort, and Richard Rabbat
   (Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for
   their useful comments.

   Thanks also to Adrian Farrel for the thorough review of the document.

12.  References

12.1.  Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Functional Description", RFC 3471,
                January 2003.

   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

   [RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
                (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4201]    Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
                in MPLS Traffic Engineering (TE)", RFC 4201, October
                2005.

   [RFC4202]    Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
                Extensions in Support of Generalized Multi-Protocol
                Label Switching (GMPLS)", RFC 4202, October 2005.

   [RFC4204]    Lang, J., Ed., "Link Management Protocol (LMP)", RFC
                4204, October 2005.

   [RFC4209]    Fredette, A., Ed. and J. Lang, Ed., "Link Management
                Protocol (LMP) for Dense Wavelength Division
                Multiplexing (DWDM) Optical Line Systems", RFC 4209,
                October 2005.

   [RFC4427]    Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery
                (Protection and Restoration) Terminology for Generalized
                Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
                2006.

12.2.  Informative References

   [BOUILLET]   E. Bouillet, et al., "Stochastic Approaches to Compute
                Shared Meshed Restored Lightpaths in Optical Network
                Architectures," IEEE Infocom 2002, New York City, June
                2002.

   [DEMEESTER]  P. Demeester, et al., "Resilience in Multilayer
                Networks," IEEE Communications Magazine, Vol. 37, No. 8,
                pp. 70-76, August 1998.

   [GLI]        G. Li, et al., "Efficient Distributed Path Selection for
                Shared Restoration Connections," IEEE Infocom 2002, New
                York City, June 2002.

   [IPO-IMP]    Strand, J. and A. Chiu, "Impairments and Other
                Constraints on Optical Layer Routing", RFC 4054, May
                2005.

   [KODIALAM1]  M. Kodialam and T.V. Lakshman, "Restorable Dynamic
                Quality of Service Routing," IEEE Communications
                Magazine, pp. 72-81, June 2002.

   [KODIALAM2]  M. Kodialam and T.V. Lakshman, "Dynamic Routing of
                Restorable Bandwidth-Guaranteed Tunnels using Aggregated
                Network Resource Usage Information," IEEE/ ACM
                Transactions on Networking, pp. 399-410, June 2003.

   [MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
                Evolution of Transport Network Survivability," IEEE
                Communications Magazine, August 1999.

   [RFC3386]    Lai, W. and D. McDysan, "Network Hierarchy and
                Multilayer Survivability", RFC 3386, November 2002.

   [T1.105]     ANSI, "Synchronous Optical Network (SONET): Basic
                Description Including Multiplex Structure, Rates, and
                Formats," ANSI T1.105, January 2001.

   [WANG]       J. Wang, L. Sahasrabuddhe, and B. Mukherjee, "Path vs.
                Subpath vs. Link Restoration for Fault Management in
                IP-over-WDM Networks: Performance Comparisons Using
                GMPLS Control Signaling," IEEE Communications Magazine,
                pp. 80-87, November 2002.

   For information on the availability of the following documents,
   please see http://www.itu.int

   [G.707]      ITU-T, "Network Node Interface for the Synchronous
                Digital Hierarchy (SDH)," Recommendation G.707, October
                2000.

   [G.709]      ITU-T, "Network Node Interface for the Optical Transport
                Network (OTN)," Recommendation G.709, February 2001 (and
                Amendment no.1, October 2001).

   [G.783]      ITU-T, "Characteristics of Synchronous Digital Hierarchy
                (SDH) Equipment Functional Blocks," Recommendation
                G.783, October 2000.

   [G.798]      ITU-T, "Characteristics of optical transport network
                hierarchy equipment functional block," Recommendation
                G.798, June 2004.

   [G.806]      ITU-T, "Characteristics of Transport Equipment -
                Description Methodology and Generic Functionality",
                Recommendation G.806, October 2000.

   [G.841]      ITU-T, "Types and Characteristics of SDH Network
                Protection Architectures," Recommendation G.841, October
                1998.

   [G.842]      ITU-T, "Interworking of SDH network protection
                architectures," Recommendation G.842, October 1998.

   [G.874]      ITU-T, "Management aspects of the optical transport
                network element," Recommendation G.874, November 2001.

Editors’ Addresses

   Dimitri Papadimitriou
   Alcatel
   Francis Wellesplein, 1
   B-2018 Antwerpen, Belgium

   Phone:  +32 3 240-8491
   EMail: dimitri.papadimitriou@alcatel.be

   Eric Mannie
   Perceval
   Rue Tenbosch, 9
   1000 Brussels
   Belgium

   Phone: +32-2-6409194
   EMail: eric.mannie@perceval.net

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   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.

Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容