GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6205

Internet Engineering Task Force (IETF) T. Otani, Ed. Request for Comments: 6205 KDDI Updates: 3471 D. Li, Ed. Category: Standards Track Huawei ISSN: 2070-1721 March 2011

         Generalized Labels for Lambda-Switch-Capable (LSC)
                      Label Switching Routers

Abstract

 Technology in the optical domain is constantly evolving, and, as a
 consequence, new equipment providing lambda switching capability has
 been developed and is currently being deployed.
 Generalized MPLS (GMPLS) is a family of protocols that can be used to
 operate networks built from a range of technologies including
 wavelength (or lambda) switching.  For this purpose, GMPLS defined a
 wavelength label as only having significance between two neighbors.
 Global wavelength semantics are not considered.
 In order to facilitate interoperability in a network composed of next
 generation lambda-switch-capable equipment, this document defines a
 standard lambda label format that is compliant with the Dense
 Wavelength Division Multiplexing (DWDM) and Coarse Wavelength
 Division Multiplexing (CWDM) grids defined by the International
 Telecommunication Union Telecommunication Standardization Sector.
 The label format defined in this document can be used in GMPLS
 signaling and routing protocols.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6205.

Otani & Li Standards Track [Page 1] RFC 6205 Generalized Labels for LSC LSRs March 2011

Copyright Notice

 Copyright (c) 2011 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
 (http://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.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

1. Introduction

 As described in [RFC3945], GMPLS extends MPLS from supporting only
 Packet Switching Capable (PSC) interfaces and switching to also
 supporting four new classes of interfaces and switching:
 o Layer-2 Switch Capable (L2SC)
 o Time-Division Multiplex (TDM) Capable
 o Lambda Switch Capable (LSC)
 o Fiber Switch Capable (FSC)
 A functional description of the extensions to MPLS signaling needed
 to support new classes of interfaces and switching is provided in
 [RFC3471].
 This document presents details that are specific to the use of GMPLS
 with LSC equipment.  Technologies such as Reconfigurable Optical
 Add/Drop Multiplex (ROADM) and Wavelength Cross-Connect (WXC) operate

Otani & Li Standards Track [Page 2] RFC 6205 Generalized Labels for LSC LSRs March 2011

 at the wavelength switching level.  [RFC3471] states that wavelength
 labels "only have significance between two neighbors" (Section
 3.2.1.1); global wavelength semantics are not considered.  In order
 to facilitate interoperability in a network composed of LSC
 equipment, this document defines a standard lambda label format,
 which is compliant with both the Dense Wavelength Division
 Multiplexing (DWDM) grid [G.694.1] and the Coarse Wavelength Division
 Multiplexing (CWDM) grid [G.694.2].

1.1. 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].

2. Assumed Network Model and Related Problem Statement

 Figure 1 depicts an all-optical switched network consisting of
 different vendors' optical network domains.  Vendor A's network
 consists of ROADM or WXC, and Vendor B's network consists of a number
 of Photonic Cross-Connects (PXCs) and DWDM multiplexers and
 demultiplexers.  Otherwise, both vendors' networks might be based on
 the same technology.
 In this case, the use of standardized wavelength label information is
 quite significant to establish a wavelength-based Label Switched Path
 (LSP).  It is also an important constraint when calculating the
 Constrained Shortest Path First (CSPF) for use by Generalized Multi-
 Protocol Label Switching (GMPLS) Resource ReserVation Protocol -
 Traffic Engineering (RSVP-TE) signaling [RFC3473].  The way the CSPF
 is performed is outside the scope of this document.
 Needless to say, an LSP must be appropriately provisioned between a
 selected pair of ports not only within Domain A but also over
 multiple domains satisfying wavelength constraints.
 Figure 2 illustrates the interconnection between Domain A and Domain
 B in detail.

Otani & Li Standards Track [Page 3] RFC 6205 Generalized Labels for LSC LSRs March 2011

                                |
    Domain A (or Vendor A)      |      Domain B (or Vendor B)
                                |
   Node-1            Node-2     |         Node-6            Node-7
 +--------+        +--------+   |      +-------+ +-+     +-+ +-------+
 | ROADM  |        | ROADM  +---|------+  PXC  +-+D|     |D+-+  PXC  |
 | or WXC +========+ or WXC +---|------+       +-+W+=====+W+-+       |
 | (LSC)  |        | (LSC)  +---|------+ (LSC) +-+D|     |D+-+ (LSC) |
 +--------+        +--------+   |      |       +-|M|     |M+-+       |
     ||                ||       |      +++++++++ +-+     +-+ +++++++++
     ||     Node-3     ||       |       |||||||               |||||||
     ||   +--------+   ||       |      +++++++++             +++++++++
     ||===|  WXC   +===||       |      | DWDM  |             | DWDM  |
          | (LSC)  |            |      +--++---+             +--++---+
     ||===+        +===||       |         ||                    ||
     ||   +--------+   ||       |      +--++---+             +--++---+
     ||                ||       |      | DWDM  |             | DWDM  |
 +--------+        +--------+   |      +++++++++             +++++++++
 | ROADM  |        | ROADM  |   |       |||||||               |||||||
 | or WXC +========+ or WXC +=+ |  +-+ +++++++++ +-+     +-+ +++++++++
 | (LSC)  |        | (LSC)  | | |  |D|-|  PXC  +-+D|     |D+-+  PXC  |
 +--------+        +--------+ +=|==+W|-|       +-+W+=====+W+-+       |
   Node-4            Node-5     |  |D|-| (LSC) +-+D|     |D+-+ (LSC) |
                                |  |M|-|       +-+M|     |M+-+       |
                                |  +-+ +-------+ +-+     +-+ +-------+
                                |        Node-8             Node-9
    Figure 1.  Wavelength-Based Network Model

Otani & Li Standards Track [Page 4] RFC 6205 Generalized Labels for LSC LSRs March 2011

 +-------------------------------------------------------------+
 |          Domain A             |        Domain B             |
 |                               |                             |
 |           +---+     lambda 1  |         +---+               |
 |           |   |---------------|---------|   |               |
 |       WDM | N |     lambda 2  |         | N | WDM           |
 |      =====| O |---------------|---------| O |=====          |
 |  O        | D |        .      |         | D |        O      |
 |  T    WDM | E |        .      |         | E | WDM    T      |
 |  H   =====| 2 |     lambda n  |         | 6 |=====   H      |
 |  E        |   |---------------|---------|   |        E      |
 |  R        +---+               |         +---+        R      |
 |                               |                             |
 |  N        +---+               |         +---+        N      |
 |  O        |   |               |         |   |        O      |
 |  D    WDM | N |               |         | N | WDM    D      |
 |  E   =====| O |      WDM      |         | O |=====   E      |
 |  S        | D |=========================| D |        S      |
 |       WDM | E |               |         | E | WDM           |
 |      =====| 5 |               |         | 8 |=====          |
 |           |   |               |         |   |               |
 |           +---+               |         +---+               |
 +-------------------------------------------------------------+
    Figure 2.  Interconnecting Details between Two Domains
 In the scenario of Figure 1, consider the setting up of a
 bidirectional LSP from ingress switch (Node-1) to egress switch
 (Node-9) using GMPLS RSVP-TE.  In order to satisfy wavelength
 continuity constraints, a fixed wavelength (lambda 1) needs to be
 used in Domain A and Domain B.  A Path message will be used for
 signaling.  The Path message will contain an Upstream_Label object
 and a Label_Set object, both containing the same value.  The
 Label_Set object shall contain a single sub-channel that must be the
 same as the Upstream_Label object.  The Path setup will continue
 downstream to egress switch (Node-9) by configuring each lambda
 switch based on the wavelength label.  If a node has a tunable
 wavelength transponder, the tuning wavelength is considered a part of
 the wavelength switching operation.
 Not using a standardized label would add undue burden on the operator
 to enforce policy as each manufacturer may decide on a different
 representation; therefore, each domain may have its own label
 formats.  Moreover, manual provisioning may lead to misconfiguration
 if domain-specific labels are used.

Otani & Li Standards Track [Page 5] RFC 6205 Generalized Labels for LSC LSRs March 2011

 Therefore, a wavelength label should be standardized in order to
 allow interoperability between multiple domains; otherwise,
 appropriate existing labels are identified in support of wavelength
 availability.  Containing identical wavelength information, the ITU-T
 DWDM frequency grid specified in [G.694.1] and the CWDM wavelength
 information in [G.694.2] are used by Label Switching Routers (LSRs)
 and should be followed for wavelength labels.

3. Label-Related Formats

 To deal with the widening scope of MPLS into the optical switching
 and time division multiplexing domains, several new forms of "label"
 have been defined in [RFC3471].  This section contains a definition
 of a wavelength label based on [G.694.1] or [G.694.2] for use by LSC
 LSRs.

3.1. Wavelength Labels

 Section 3.2.1.1 of [RFC3471] defines wavelength labels: "values used
 in this field only have significance between two neighbors, and the
 receiver may need to convert the received value into a value that has
 local significance".
 We do not need to define a new type as the information stored is
 either a port label or a wavelength label.  Only the wavelength label
 needs to be defined.
 LSC equipment uses multiple wavelengths controlled by a single
 control channel.  In such a case, the label indicates the wavelength
 to be used for the LSP.  This document defines a standardized
 wavelength label format.  For examples of wavelength values, refer to
 [G.694.1], which lists the frequencies from the ITU-T DWDM frequency
 grid.  For CWDM technology, refer to the wavelength values defined in
 [G.694.2].
 Since the ITU-T DWDM grid is based on nominal central frequencies, we
 need to indicate the appropriate table, the channel spacing in the
 grid, and a value n that allows the calculation of the frequency.
 That value can be positive or negative.
 The frequency is calculated as such in [G.694.1]:
      Frequency (THz) = 193.1 THz + n * channel spacing (THz)
 Where "n" is a two's-complement integer (positive, negative, or 0)
 and "channel spacing" is defined to be 0.0125, 0.025, 0.05, or 0.1
 THz.  When wider channel spacing such as 0.2 THz is utilized, the
 combination of narrower channel spacing and the value "n" can provide

Otani & Li Standards Track [Page 6] RFC 6205 Generalized Labels for LSC LSRs March 2011

 proper frequency with that channel spacing.  Channel spacing is not
 utilized to indicate the LSR capability but only to specify a
 frequency in signaling.
 For other cases that use the ITU-T CWDM grid, the spacing between
 different channels is defined as 20 nm, so we need to express the
 wavelength value in nanometers (nm).  Examples of CWDM wavelengths in
 nm are 1471, 1491, etc.
 The wavelength is calculated as follows:
      Wavelength (nm) = 1471 nm + n * 20 nm
 Where "n" is a two's-complement integer (positive, negative, or 0).
 The grids listed in [G.694.1] and [G.694.2] are not numbered and
 change with the changing frequency spacing as technology advances, so
 an index is not appropriate in this case.

3.2. DWDM Wavelength Label

 For the case of lambda switching of DWDM, the information carried in
 a wavelength label 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid | C.S.  |    Identifier   |              n                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (1) Grid: 3 bits
 The value for Grid is set to 1 for the ITU-T DWDM grid as defined in
 [G.694.1].
 +----------+---------+
 |   Grid   |  Value  |
 +----------+---------+
 | Reserved |    0    |
 +----------+---------+
 |ITU-T DWDM|    1    |
 +----------+---------+
 |ITU-T CWDM|    2    |
 +----------+---------+
 |Future use|  3 - 7  |
 +----------+---------+
 (2) C.S. (channel spacing): 4 bits

Otani & Li Standards Track [Page 7] RFC 6205 Generalized Labels for LSC LSRs March 2011

 DWDM channel spacing is defined as follows.
 +----------+---------+
 |C.S. (GHz)|  Value  |
 +----------+---------+
 | Reserved |    0    |
 +----------+---------+
 |    100   |    1    |
 +----------+---------+
 |    50    |    2    |
 +----------+---------+
 |    25    |    3    |
 +----------+---------+
 |    12.5  |    4    |
 +----------+---------+
 |Future use|  5 - 15 |
 +----------+---------+
 (3) Identifier: 9 bits
 The Identifier field in lambda label format is used to distinguish
 different lasers (in one node) when they can transmit the same
 frequency lambda.  The Identifier field is a per-node assigned and
 scoped value.  This field MAY change on a per-hop basis.  In all
 cases but one, a node MAY select any value, including zero (0), for
 this field.  Once selected, the value MUST NOT change until the LSP
 is torn down, and the value MUST be used in all LSP-related messages,
 e.g., in Resv messages and label Record Route Object (RRO)
 subobjects.  The sole special case occurs when this label format is
 used in a label Explicit Route Object (ERO) subobject.  In this case,
 the special value of zero (0) means that the referenced node MAY
 assign any Identifier field value, including zero (0), when
 establishing the corresponding LSP.  When a non-zero value is
 assigned to the Identifier field in a label ERO subobject, the
 referenced node MUST use the assigned value for the Identifier field
 in the corresponding LSP-related messages.
 (4) n: 16 bits
 n is a two's-complement integer to take either a positive, negative,
 or zero value.  This value is used to compute the frequency as shown
 above.

3.3. CWDM Wavelength Label

 For the case of lambda switching of CWDM, the information carried in
 a wavelength label is:

Otani & Li Standards Track [Page 8] RFC 6205 Generalized Labels for LSC LSRs March 2011

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid | C.S.  |    Identifier   |                n              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The structure of the label in the case of CWDM is the same as that of
 the DWDM case.
 (1) Grid: 3 bits
 The value for Grid is set to 2 for the ITU-T CWDM grid as defined in
 [G.694.2].
 +----------+---------+
 |   Grid   |  Value  |
 +----------+---------+
 | Reserved |    0    |
 +----------+---------+
 |ITU-T DWDM|    1    |
 +----------+---------+
 |ITU-T CWDM|    2    |
 +----------+---------+
 |Future use|  3 - 7  |
 +----------+---------+
 (2) C.S. (channel spacing): 4 bits
 CWDM channel spacing is defined as follows.
 +----------+---------+
 |C.S. (nm) |  Value  |
 +----------+---------+
 | Reserved |    0    |
 +----------+---------+
 |    20    |    1    |
 +----------+---------+
 |Future use|  2 - 15 |
 +----------+---------+
 (3) Identifier: 9 bits
 The Identifier field in lambda label format is used to distinguish
 different lasers (in one node) when they can transmit the same
 frequency lambda.  The Identifier field is a per-node assigned and
 scoped value.  This field MAY change on a per-hop basis.  In all
 cases but one, a node MAY select any value, including zero (0), for
 this field.  Once selected, the value MUST NOT change until the LSP

Otani & Li Standards Track [Page 9] RFC 6205 Generalized Labels for LSC LSRs March 2011

 is torn down, and the value MUST be used in all LSP-related messages,
 e.g., in Resv messages and label RRO subobjects.  The sole special
 case occurs when this label format is used in a label ERO subobject.
 In this case, the special value of zero (0) means that the referenced
 node MAY assign any Identifier field value, including zero (0), when
 establishing the corresponding LSP.  When a non-zero value is
 assigned to the Identifier field in a label ERO subobject, the
 referenced node MUST use the assigned value for the Identifier field
 in the corresponding LSP-related messages.
 (4) n: 16 bits
 n is a two's-complement integer.  This value is used to compute the
 wavelength as shown above.

4. Security Considerations

 This document introduces no new security considerations to [RFC3471]
 and [RFC3473].  For a general discussion on MPLS and GMPLS-related
 security issues, see the MPLS/GMPLS security framework [RFC5920].

5. IANA Considerations

 IANA maintains the "Generalized Multi-Protocol Label Switching
 (GMPLS) Signaling Parameters" registry.  IANA has added three new
 subregistries to track the codepoints (Grid and C.S.)  used in the
 DWDM and CWDM wavelength labels, which are described in the following
 sections.

5.1. Grid Subregistry

 Initial entries in this subregistry are as follows:
 Value   Grid                         Reference
 -----   -------------------------    ----------
   0     Reserved                     [RFC6205]
   1     ITU-T DWDM                   [RFC6205]
   2     ITU-T CWDM                   [RFC6205]
  3-7    Unassigned                   [RFC6205]
 New values are assigned according to Standards Action.

Otani & Li Standards Track [Page 10] RFC 6205 Generalized Labels for LSC LSRs March 2011

5.2. DWDM Channel Spacing Subregistry

 Initial entries in this subregistry are as follows:
 Value   Channel Spacing (GHz)        Reference
 -----   -------------------------    ----------
   0     Reserved                     [RFC6205]
   1     100                          [RFC6205]
   2     50                           [RFC6205]
   3     25                           [RFC6205]
   4     12.5                         [RFC6205]
  5-15   Unassigned                   [RFC6205]
 New values are assigned according to Standards Action.

5.3. CWDM Channel Spacing Subregistry

 Initial entries in this subregistry are as follows:
 Value   Channel Spacing (nm)         Reference
 -----   -------------------------    ----------
 0       Reserved                     [RFC6205]
 1       20                           [RFC6205]
 2-15    Unassigned                   [RFC6205]
 New values are assigned according to Standards Action.

6. Acknowledgments

 The authors would like to thank Adrian Farrel, Lou Berger, Lawrence
 Mao, Zafar Ali, and Daniele Ceccarelli for the discussion and their
 comments.

7. References

7.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., Ed., "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.

Otani & Li Standards Track [Page 11] RFC 6205 Generalized Labels for LSC LSRs March 2011

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

7.2. Informative References

 [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.
 [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, July 2010.

Otani & Li Standards Track [Page 12] RFC 6205 Generalized Labels for LSC LSRs March 2011

Appendix A. DWDM Example

 Considering the network displayed in Figure 1, it is possible to show
 an example of LSP setup using the lambda labels.
 Node 1 receives the request for establishing an LSP from itself to
 Node 9.  The ITU-T grid to be used is the DWDM one, the channel
 spacing is 50 Ghz, and the wavelength to be used is 193,35 THz.
 Node 1 signals the LSP via a Path message including a wavelength
 label structured as defined in Section 3.2:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |   Identifier    |              n                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Where:
 Grid = 1 : ITU-T DWDM grid
 C.S. = 2 : 50 GHz channel spacing
 n    = 5 :
      Frequency (THz) = 193.1 THz + n * channel spacing (THz)
      193.35 (THz) = 193.1 (THz) + n* 0.05 (THz)
      n = (193.35-193.1)/0.05 = 5

Appendix B. CWDM Example

 The network displayed in Figure 1 can also be used to display an
 example of signaling using the wavelength label in a CWDM
 environment.
 This time, the signaling of an LSP from Node 4 to Node 7 is
 considered.  Such LSP exploits the CWDM ITU-T grid with a 20 nm
 channel spacing and is established using a wavelength equal to 1331
 nm.
 Node 4 signals the LSP via a Path message including a wavelength
 label structured as defined in Section 3.3:

Otani & Li Standards Track [Page 13] RFC 6205 Generalized Labels for LSC LSRs March 2011

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |   Identifier    |              n                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Where:
 Grid = 2 : ITU-T CWDM grid
 C.S. = 1 : 20 nm channel spacing
 n    = -7 :
      Wavelength (nm) = 1471 nm + n * 20 nm
      1331 (nm) = 1471 (nm) + n * 20 nm
      n = (1331-1471)/20 = -7

Authors' Addresses

 Richard Rabbat
 Google, Inc.
 1600 Amphitheatre Parkway
 Mountain View, CA 94043
 USA
 EMail: rabbat@alum.mit.edu
 Sidney Shiba
 EMail: sidney.shiba@att.net
 Hongxiang Guo
 EMail: hongxiang.guo@gmail.com
 Keiji Miyazaki
 Fujitsu Laboratories Ltd
 4-1-1 Kotanaka Nakahara-ku,
 Kawasaki Kanagawa, 211-8588
 Japan
 Phone: +81-44-754-2765
 EMail: miyazaki.keiji@jp.fujitsu.com

Otani & Li Standards Track [Page 14] RFC 6205 Generalized Labels for LSC LSRs March 2011

 Diego Caviglia
 Ericsson
 16153 Genova Cornigliano
 Italy
 Phone: +390106003736
 EMail: diego.caviglia@ericsson.com
 Takehiro Tsuritani
 KDDI R&D Laboratories Inc.
 2-1-15 Ohara Fujimino-shi
 Saitama, 356-8502
 Japan
 Phone:  +81-49-278-7806
 EMail:  tsuri@kddilabs.jp

Editors' Addresses

 Tomohiro Otani (editor)
 KDDI Corporation
 2-3-2 Nishishinjuku Shinjuku-ku
 Tokyo, 163-8003
 Japan
 Phone:  +81-3-3347-6006
 EMail:  tm-otani@kddi.com
 Dan Li (editor)
 Huawei Technologies
 F3-5-B R&D Center, Huawei Base,
 Shenzhen 518129
 China
 Phone: +86 755-289-70230
 EMail: danli@huawei.com

Otani & Li Standards Track [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6205.txt · Last modified: 2011/03/27 09:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki