INTERNET DRAFT Avri Doria
GSMP Working Group Kenneth Sundell
Informational Track Stephen Shew
Nortel Networks
Feb 2001
Requirements for adding Optical Switch Support to GSMP
<draft-doria-gsmp-req-olsr-01.txt>
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo provides an overview of the requirements on the GSMP
protocol for support of optical switching.
Doria et. al. Expires September 2001 [Page 1]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
Table of Contents
ABSTRACT............................................................. 1
TABLE OF CONTENTS ................................................... 2
1. OVERVIEW.......................................................... 3
2. LABEL TYPES....................................................... 3
3. PORT AND LABEL MANAGEMENT ISSUES ................................. 4
4. STATISTICS MESSAGES .............................................. 4
5. CONFIGURATION ISSUES ............................................. 4
5.1 Switch Configuration ........................................... 4
5.2 Port Configuration ............................................. 4
5.3 Service Configuration .......................................... 4
6. SERVICE MODEL ISSUES ............................................. 5
7. ENCAPSULATION ISSUES ............................................. 5
8. MIB ISSUES........................................................ 5
9. OXC TRANSACTION MODEL ............................................ 5
9.1 Serial Transactions ............................................ 5
9.2 Bulk Transactions .............................................. 6
10. OXC RESTORATION CAPABILITIES .................................... 6
10.1 Non-Reserved Protection Links ................................. 6
10.2 Reserved Protection Links ..................................... 6
11. SECURITY CONSIDERATIONS ......................................... 7
REFERENCES........................................................... 7
FULL COPYRIGHT STATEMENT ............................................ 9
Doria et. al. Expires September 2001 [Page 2]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
1. Overview
This draft is intended to describe the required changes to GSMP
for support of optical, SONET/SDH, and spatial switching of IP
packets and flows. It is uncertain at this point what the mix of
implementations will be, but the possibilities include: IP based
optical routers, optical label switches, wavelength routers, and
optical cross connects. There are also several different generic
models that might be applied to running IP over WDM [1][2]. One
item which seems probable, however, is that it will be
advantageous to separate the control functions from the data
functions in order to provide a more flexible network
architecture.[3]
In this draft, no position will be taken about the eventual
architectural model that will be most appropriate. The only
assumption is that the ability to separate the control mechanisms
from the data switching is as useful in GMPLS as it is in current
MPLS technology.
GSMPv3[6] is well suited for providing the control mechanisms
necessary for allowing an IP based controller to direct the
activities of an optical switch. In order for GSMP to operate
between IP controllers and optical switches and cross connects,
support for optical labels and service and resource abstractions
must be added to GSMP.
2. Label Types
New labels are needed to identify the entities that are to be
switched in the optical fabric. These are longer than GSMPv3
labels as they have physical and structural context. As
GMPLS[1][2] has had very similar requirements for label formats
alignment with GMPLS is proposed. This includes support for:
- Digital Carrier Hierarchy (e.g., DS-1, J-1, E1)
- SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12)
- Lambdas
- Fibers
GSMP MUST include support for all label types as well as for label
hierarchies and label lists as defined by GMPLS[1][2].
Bundles of the above labels SHOULD also be supported (e.g., 5 OC-
3s)
Doria et. al. Expires September 2001 [Page 3]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
3. Port and Label Management Issues
No changes are currently seen as needed in the port management
message.
An updated label range message MUST be provided. There MUST also
be support of multiplexing (e.g. no multiplexing, SONET
multiplexing, Gigabit Ethernet multiplexing etc).
4. Statistics messages
No changes are currently proposed for the statistics messages to
support optical switching.
5. Configuration Issues
5.1 Switch Configuration
No changes are currently proposed for the switch configuration
messages to support optical switching.
5.2 Port Configuration
The port configuration message supplies the controller with the
configuration information related to a single port. In order to
handle the specific port types in a WDM switch, extensive
additions will need to be made to this command.
Port types MUST be added to support the mix of SONET signals that
can operate over a single fiber. Information that MAY need to be
conveyed includes[8]:
- wavelengths available on the fiber
- serial bit rate per wavelength
- type of fiber
5.3 Service Configuration
While new capability sets MUST be added to support quality
parameters in optical switches, no changes are foreseen to the
service configuration message as its role to carry the service
information as defined in the applicable service model. The
changes related to the service model will be discussed in section
6.
Doria et. al. Expires September 2001 [Page 4]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
6. Service Model Issues
While one assumption of using optical media is that bandwidth is
plentiful, it should be expected that traffic engineering will be
necessary in any case[3]. GSMP provides the means for each
connection, or in this each light trail, to be created with
specific quality attributes. Capability to control re-timing and
re-shaping MUST be added.
Currently, the default set of service models in GSMP are all based
on the services models defined elsewhere, e.g. the Intserv
model[5][7], the Diffserv[4] model, ATM QoS models and the Frame
relay forum QoS models. A determination needs to be made of the
applicable quality models for optical channel trails. These models
MUST then be mapped to the GSMP capability set mechanism.
7. Encapsulation issues
The working group needs to decide whether a new encapsulation is
required. In other words, will all optical switches used in
either the MPLS over Optics and the IP over optics applications
require that IP be implemented on the control channel connecting
the GSMP controller and Optical switch (the GSMP target). If a
raw wavelength control connection is to be allowed, a new
encapsulation SHOULD be defined.
8. MIB issues
If a new encapsulation is defined, then the encapsulation group
SHOULD be updated. No other changes should be required.
9. OXC Transaction Model
9.1 Serial Transactions
Many existing OXCs use a command interface which assumes a serial
transaction model. That is, a new command cannot be issued or
processed until the existing command is completed. Under
provisioning control via a network management application, and
with non-dynamic path setup, this model has been adequate.
Moving to a dynamic path setup capability with a distributed
control plane, a parallel transaction model is likely required for
performance. This is particularly helpful when the performance of
setting up a TDM style connection is much slower than setting up
an L2 connection table. If the OXC is not able to support a
parallel transaction model, a GSMP controller MUST be informed of
this and adopt serial transaction behaviour.
Doria et. al. Expires September 2001 [Page 5]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
9.2 Bulk Transactions
Again due to the time it may take some OXCs to setup TDM
connections relative to L2 fabrics, support for sending multiple
transactions in the same message is a useful optimization. When
an OXC receives a bulk message, the individual transactions are
acted upon and a single reply is sent. If parallel transactions
are not supported, bulk messages can improve performance by
reducing transaction overhead. Bulk transactions SHOULD be
supported.
10. OXC Restoration Capabilities
To achieve fast link protection performance (e.g., 50 ms after
failure detection), SONET/SDH and some WDM systems use hardware
based protection schemes (e.g., ring protection). Achieving this
level of performance solely using a data control plane such as
GMPLS is a serious challenge. An alternate approach is to utilize
fast restoration capabilities of an OXC with a dynamic control
plane.
An implication of this hybrid approach is that extensions are
needed to GSMP to provision the behaviour of an OXC in
anticipation of a link failure.
10.1 Non-Reserved Protection Links
An example of protection OXC behaviour is that when a link fails,
a backup link may be used to protect traffic on. This backup link
could be selected from a set of links, none of which are pre-
reserved. A backup link could be shared with one or more
"working" links which is a form of 1:n protection. Specifying the
set of possible backup links SHOULD be done as an option to the
Add-Branch message.
When a backup link is used, the control plane (i.e., signalling)
may need to know about the new path state in order to notify the
operator, or take some other OAM action (e.g., billing, SLA
monitoring). An additional GSMP message to inform the controller
SHOULD be added to do this.
10.2 Reserved Protection Links
A more specialized form of restoration called "1+1" reserves a
backup link for a given working link. This backup link is not
shared with any other working link and traffic is sent over both
working and protection links. Specifying the backup link should
be done when the Add-Branch message is sent. This SHOULD be an
option to that message. When any link in the working path fails,
Doria et. al. Expires September 2001 [Page 6]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
traffic on the working path ceases to be received at end of the
path.
If an alternate input port is not specified with an original Add-
Branch message, it MAY be specified in a subsequent Add-Branch
message. In this case, it is useful to include information about
existing users of the output port in that Add-Branch message.
This helps the OXC immediately learn of the association between
the new input port and an existing one. The association is used
to enable OXC protection procedures. This capability MUST be added
to the add-branch message.
Similar contextual information is needed for a Delete-Branch
message so that the OXC can determine if a path becomes
unprotected. This capability MUST be added to the Delete-branch
message.
11. Security Considerations
The security of GSMP's TCP/IP control channel has been addressed
in [10]. Any potential remaining security considerations are not
addressed in the current revision of this draft.
References
[1] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling
Functional Description", Internet Draft draft-
ietf-mpls-generalized-signaling-01.txt (work in
progress), November 2000.
[2] Ashwood-Smith, D., et. al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", draft-
many-gmpls-architecture-oo.txt (work in
progress), February 2001
[3] Awduche, D, Rekhter, Y, et. al., "Multi-Protocol Lambda
Switching: Combining MPLS Traffic Engineering
Control with Optical Crossconnects," draft-
awduche-mpls-te-optical-02.txt (work in
progress), July, 2000
[4] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC2475, December 1998
[5] Braden, R., "Integrated Services in the Internet
Architecture: An Overview", RFC1633, June 1994
Doria et. al. Expires September 2001 [Page 7]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
[6] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General
Switch Management Protocol V3," Internet Draft
draft-ietf-gsmp-08.txt (work in progress),
December 2000
[7] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service," RFC2211, Sep 1997.
[8] Rajagopalan, B., et. al., "IP over Optical Networks: A
Framework", draft-many-ip-optical-framework-
02.txt (work in progress), November 2000
[9] Sjostrand, H, et al, Definitions of Managed Objects for
the General Switch Management Protocol (GSMP),"
Internet-Draft draft-ietf-gsmp-mib-04 (work in
progress), December 2000.
[10] Worster, T, et al, "GSMP Packet Encapsulations for ATM,
Ethernet and TCP," Internet-Draft draft-ietf-
gsmp-encaps-03 (work in progress), December
2000.
Doria et. al. Expires September 2001 [Page 8]
Internet Draft Req. for Optical Support in GSMP 2001-03-02
Author's Addresses
Avri Doria
Nortel Networks
600 Technology Park Drive
Billerica MA 01821
avri@nortelnetworks.com
Kenneth Sundell
Nortel Networks AB
P.O. Box 6701
SE-113 85 Stockholm Sweden
ksundell@nortelnetworks.com
Stephen Shew
Nortel Networks
PO Box 3511 Station C
Ottawa, ON
K1Y 4H7
Sdshew@nortelnetworks.com
Full Copyright Statement
"Copyright (C) The Internet Society 2001. 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.
Doria et. al. Expires September 2001 [Page 9]
