Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-06

opsawg                                                             Z. Li
Internet-Draft                                                     R. Gu
Intended status: Standards Track                            China Mobile
Expires: March 29, 2019                                          J. Dong
                                                     Huawei Technologies
                                                      September 25, 2018

 Export BGP community information in IP Flow Information Export (IPFIX)
                draft-ietf-opsawg-ipfix-bgp-community-09

Abstract

   By introducing new Information Elements (IEs), this draft extends the
   existing BGP related IEs to enable IPFIX [RFC7011] to export the BGP
   community information, including the information of BGP standard
   community [RFC1997], BGP extended community [RFC4360], and BGP large
   community [RFC8092].  Network traffic information can then be
   accumulated and analysed at the BGP community granularity, which
   represents the traffic of different kinds of customers, services, or
   geographical regions according to the network operator's BGP
   community planning.  Network traffic information at the BGP community
   granularity is useful for network traffic analysis and engineering.

   To clarify, no new BGP community attribute is defined in this
   document and this document has no purpose to replace BGP Monitoring
   Protocol (BMP) defined in RFC7854.  The IEs introduced in this
   document are used by IPFIX together with other IEs to facilitate the
   IPFIX Collector analyzing the network traffic at the BGP community
   granularity without running the heavy BGP protocol.  When needed, the
   IPFIX Mediator or Collector can use the IEs introduced in this
   document to report the BGP community related traffic flow information
   it gets either from Exporters or through local correlation to other
   IPFIX devices.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any

Li, et al.               Expires March 29, 2019                 [Page 1]
Internet-Draft        Export BGP Community in IPFIX       September 2018

   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 29, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  BGP Community based Traffic Collection  . . . . . . . . . . .   5
   4.  IEs for BGP Standard Community  . . . . . . . . . . . . . . .   7
   5.  IEs for BGP Extended Community  . . . . . . . . . . . . . . .   7
   6.  IEs for BGP Large Community . . . . . . . . . . . . . . . . .   7
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Encoding Example . . . . . . . . . . . . . . . . . .  13
     A.1.  Template Record . . . . . . . . . . . . . . . . . . . . .  13
     A.2.  Data Set  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   IP Flow Information Export (IPFIX) [RFC7011] provides network
   administrators with traffic flow information using the Information
   Elements (IEs) defined in [IANA-IPFIX] registries.  Based on the
   traffic flow information, network administrators know the amount and
   direction of the traffic in their network, then they can optimize
   their network when needed.  For example, they can shift some flows

Li, et al.               Expires March 29, 2019                 [Page 2]
Internet-Draft        Export BGP Community in IPFIX       September 2018

   from the congested links to the low utilized links through a SDN
   controller or PCE [RFC4655].

   [IANA-IPFIX] has already defined the following IEs for traffic flow
   information exporting in different granularities: sourceIPv4Address,
   sourceIPv4Prefix, destinationIPv4Address, destinationIPv4Prefix,
   bgpSourceAsNumber, bgpDestinationAsNumber, bgpNextHopIPv4Address,
   etc.  In some circumstances, however, especially when traffic
   engineering and optimization are executed in the Tier 1 or Tier 2
   operators' backbone networks, traffic flow information based on these
   IEs may not be suitable.  Flow information based on IP address or IP
   prefix may provide much too fine granularity for a large network.  On
   the contrary, flow information based on AS number may be too coarse.

   BGP community is a BGP path attribute defined in IDR (Inter Domain
   Routing) working group.  The already defined BGP community attribute
   includes the standard community defined in [RFC1997], the extended
   community defined in [RFC4360], and the large community defined in
   [RFC8092].  BGP community attribute has a variety of use cases, one
   practice of which is to use BGP community with planned specific
   values to represent the groups of customers, services, geographical
   and topological regions, which is used by a lot of operators in their
   field networks.  Please refer to [RFC4384], [RFC8195] and Section 3
   of this document for the detailed examples.  To know the traffic
   generated by different kinds of customers, from different
   geographical or topological regions, by different kinds of customers
   in different regions, we need the corresponding community information
   related to the traffic flow exported by IPFIX.  Network traffic
   statistics at the BGP community granularity is useful not only for
   the traffic analyzing, but also can then be used by other
   applications, such as the traffic optimization applications located
   in IPFIX Collector, SDN controller or PCE.  [Community-TE] also
   states analyzing network traffic information at the BGP community
   granularity is prefered for inbound traffic engineering.  However,
   there is no IE defined for BGP community attribute in [IANA-IPFIX]
   yet.

   Flow information based on BGP community may be collected by an IPFIX
   Mediator defined in [RFC6183].  IPFIX Mediator is responsible for the
   correlation between flow information and BGP community.  However no
   IEs are defined in [RFC6183] for exporting BGP community information
   in IPFIX.  Furthermore, to correlate the BGP community with the flow
   information, the IPFIX Mediator needs to learn BGP routes and perform
   lookup in the BGP routing table to get the matching entry for a
   specific flow.  Neither BGP route learning nor routing table lookup
   is trivial for an IPFIX Mediator.  The IPFIX Mediator is mainly
   introduced to release the performance requirement for the Exporter
   [RFC5982].  In fact, to obtain the information for the already

Li, et al.               Expires March 29, 2019                 [Page 3]
Internet-Draft        Export BGP Community in IPFIX       September 2018

   5. Bidirectional Lightpath Setup

   With the wavelength continuity constraint in CI-incapable [RFC3471]
   WSONs, where the nodes in the networks cannot support wavelength
   conversion, the same wavelength on each link along a unidirectional
   lightpath should be reserved. In addition to the wavelength
   continuity constraint, requirement 3.3 gives us another constraint
   on wavelength usage in data plane, in particular, it requires the
   same wavelength to be used in both directions. [RFC6163] in section
   6.1 reports on the implication to GMPLS signaling related to both
   bi-directionality and Distributed Wavelengths Assignment.

   Current GMPLS solution defines a bidirectional LSP (as defined by
   [RFC3471]). The label distribution is based on Label_Set and
   Upstream_Label objects. In case of specific constraints such as the
   same wavelengths in both directions, it may require several
   signaling attempts using information from the Acceptable_Label_Set
   received from path error messages. Since this mechanism is currently
   available and proven to work, no additional extensions are needed
   for WSON. Potential optimizations are left for further studies.

   The usage of WSON Processing object for the bidirectional case is
   the same as per unidirectional. When an intermediate node uses
   information from this object to instruct a node about wavelength
   regeneration, the same information applies to both downstream and
   upstream directions.

   Some implementations may prefer using two unidirectional LSPs. This
   solution has been always available as per [RFC3209] however recent
   work introduces the association concept [RFC4872] and [ASSOC-Info].
   Recent transport evolutions [ASSOC-ext] provide a way to associate
   two unidirectional LSPs as a bidirectional LSP. In line with this, a
   small extension can make this approach work for the WSON case.

6. Security Considerations

   This document has no requirement for a change to the security models
   within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE,
   and PCEP security models could be operated unchanged.

   However satisfying the requirements for RWA using the existing

Bernstein et al.       Expires January 5, 2014                [Page 10]
Internet-Draft        WSON Signaling Extensions               July 2013

   protocols may significantly affect the loading of those protocols.
   This makes the operation of the network more vulnerable to denial of
   service attacks. Therefore additional care maybe required to ensure
   that the protocols are secure in the WSON environment.

   Furthermore the additional information distributed in order to
   address the RWA problem represents a disclosure of network
   capabilities that an operator may wish to keep private.
   Consideration should be given to securing this information.

7. IANA Considerations

   A new LSP_REQUIRED_ATTRIBUTE type is required

   TBA:  WSON Processing Object (Section 4.2)

   Two types of sub-TLV are allowed within the WSON Processing Object

   Value                   Sub-TLV

     1 (Proposed)          WSON Processing Capabilities (Section 4.3)

     2 (Proposed)          WSON Wavelength Assignments (Section 4.4)

8. Acknowledgments

   Authors would like to thanks Lou Berger and Cyril Margaria for
   comments and suggestions.

Bernstein et al.       Expires January 5, 2014                [Page 11]
Internet-Draft        WSON Signaling Extensions               July 2013

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.

   [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
             "Structure of Management Information Version 2 (SMIv2)",
             STD 58, RFC 2578, April 1999.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.

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

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

   [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
             in Resource ReSerVation Protocol - Traffic Engineering
             (RSVP-TE)", RFC 3477, January 2003.

   [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
             Ayyangar, " Encoding of Attributes for MPLS LSP
             Establishment Using Resource Reservation Protocol Traffic
             Engineering (RSVP-TE)", RFC 5420, February 2006.

   [WSON-Encode]  Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing
             and Wavelength Assignment Information Encoding for
             Wavelength Switched Optical Networks", draft-ietf-ccamp-
             rwa-wson-encode-20 (work in progress).

   [RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf-
             ccamp-lsp-attribute-ro (work in progress).

Bernstein et al.       Expires January 5, 2014                [Page 12]
Internet-Draft        WSON Signaling Extensions               July 2013

9.2. Informative References

   [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
             and Network Element Compatibility for Wavelength Switched
             Optical Networks", work in progress: draft-lee-ccamp-wson-
             signal-compatibility-OSPF.

   [RFC6163]  Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
             and PCE Control of Wavelength Switched Optical Networks",
             work in progress: draft-bernstein-ccamp-wavelength-
             switched-03.txt, February 2008.

   [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
             Wavelength Assignment Information Model for Wavelength
             Switched Optical Networks", work in progress: draft-ietf-
             ccamp-rwa-info-18.

   [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
             and wavelength assignment approaches for wavelength-routed
             optical WDM networks", Optical Networks Magazine, January
             2000.

   [Xu]     S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE
             for Bidirectional Lightpath the Same Wavelength", work in
             progress: draft-xu-rsvpte-bidir-wave-01, November 2007.

   [Winzer06]    Peter J. Winzer and Rene-Jean Essiambre, "Advanced
             Optical Modulation Formats", Proceedings of the IEEE, vol.
             94, no. 5, pp. 952-985, May 2006.

   [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network
             Physical Layer Interfaces, March 2006.

   [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
             applications: DWDM frequency grid, June 2002.

   [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
             applications: CWDM wavelength grid, December 2003.

   [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R
             in optical transport networks (OTN), November 2006.

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

Bernstein et al.       Expires January 5, 2014                [Page 13]
Internet-Draft        WSON Signaling Extensions               July 2013

   [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
             Extensions in Support of End-to-End Generalized Multi-
             Protocol Label Switching (GMPLS) Recovery", RFC 4872,

   [ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of
             The RSVP Association Object", draft-ietf-ccamp-assoc-info-
             00 (work in progress), October 2010.

   [ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish
             Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-
             te-ext-associated-lsp-03 (work in progress), February
             2011.

Bernstein et al.       Expires January 5, 2014                [Page 14]
Internet-Draft        WSON Signaling Extensions               July 2013

Author's Addresses

   Greg M. Bernstein (editor)
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com

   Nicola Andriolli
   Scuola Superiore Sant'Anna, Pisa, Italy
   Email: nick@sssup.it

   Alessio Giorgetti
   Scuola Superiore Sant'Anna, Pisa, Italy
   Email: a.giorgetti@sssup.it

   Lin Guo
   Key Laboratory of Optical Communication and Lightwave Technologies
   Ministry of Education
   P.O. Box 128, Beijing University of Posts and Telecommunications,
   P.R.China
   Email: guolintom@gmail.com

   Hiroaki Harai
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Koganei,
   Tokyo, 184-8795 Japan

   Phone: +81 42-327-5418
   Email: harai@nict.go.jp

   Yuefeng Ji
   Key Laboratory of Optical Communication and Lightwave Technologies
   Ministry of Education
   P.O. Box 128, Beijing University of Posts and Telecommunications,
   P.R.China
   Email: jyf@bupt.edu.cn

   Daniel King
   Old Dog Consulting

   Email: daniel@olddog.co.uk

   Young Lee (editor)
   Huawei Technologies

Bernstein et al.       Expires January 5, 2014                [Page 15]
Internet-Draft        WSON Signaling Extensions               July 2013

   5360 Legacy Dr. Building 3
   Plano, TX 75024
   USA

   Phone: (469) 277-5838
   Email: leeyoung@huawei.com

   Sugang Xu
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Koganei,
   Tokyo, 184-8795 Japan

   Phone: +81 42-327-6927
   Email: xsg@nict.go.jp

   Giovanni Martinelli
   Cisco
   Via Philips 12
   20052 Monza, IT

   Phone: +39 039-209-2044
   Email: giomarti@cisco.com

Intellectual Property Statement

   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

Bernstein et al.       Expires January 5, 2014                [Page 16]
Internet-Draft        WSON Signaling Extensions               July 2013

   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.

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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Bernstein et al.       Expires January 5, 2014                [Page 17]