VBR.2: Two policers, CLP Selective, Discard
VBR.3: Two policers, CLP Selective, Tagging
UBR.1: One policer, All Cells, Discard
UBR.2: One policer, All Cells, Tagging.
x: Unused
Regulator Parameters
Only connections of style "QoS Connection" require the
Regulator Parameters to be specified in the QoS Connection
Management message. For connections of style "QoS Class
Connection" and "QoS Class Member" the Regulator Parameters
are specified in the QoS Class Establishment message.
The Regulator Parameters are specified in a similar manner
to the UPC parameters. If the regulator function is
specified as Policing, a single GCRA policer is applied to
all cells (both CLP=0 and CLP=1) on the connection. The
policer takes two parameters: an increment, the Regulator
Increment, and a limit, the Regulator Limit. The reciprocal
of the increment (1/I) specifies the rate being policed.
The limit (L) specifies the burst tolerance. (For
comparison with the token bucket policer discussed in
[Partridge], the size of the token bucket is given by L/I.)
The Regulator Increment and Regulator Limit parameters are
32-bit unsigned integers. Their values are determined in
terms of the Scaling Factor specified by the switch in the
QoS Configuration Parameters message. To determine the
value of the Regulator Increment parameter from the desired
policed rate given in cells per second:
Regulator Increment = (Scaling_Factor)/(policed_rate)
For a policed rate (r) the GCRA policer guarantees that
over any time period T the amount of traffic determined by
the policer to be conforming to the traffic parameters does
not exceed:
rT + L/I
The value of the Regulator Limit may be determined from
this relation.
If the regulator function is specified as Shaping, only the
Regulator Increment parameter is used. The Regulator Limit
parameter is not used. The value of the Regulator Increment
parameter is determined in terms of the Scaling Factor
specified by the switch in the QoS Configuration Parameters
message. To determine the value of the Regulator Increment
parameter from the desired shaper rate, given in cells per
second, on output from the shaper:
Regulator Increment = (Scaling_Factor)/(shaper_rate)
An Increment value of zero is used to disable the policer.
In this case all cells on that connection will be
considered to conform to the policer traffic parameters. A
shaper given a Regulator Increment parameter of zero will
perform no shaping function on that connection.
The Regulator Parameters have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.7 QoS Failure Response Codes
A failure response message is formed by returning the request message
that caused the failure with the Result field in the header
indicating failure (Result = 4) and the Code field giving the failure
code. The failure code specifies the reason for the switch being
unable to satisfy the request message. The following additional
failure codes are defined for use in response to QoS messages.
General failure codes are specified in Section 3.2, Failure Response
Messages.
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
10. Adjacency Protocol
The adjacency protocol is used to synchronize state across the link,
to agree on which version of the protocol to use, to discover the
identity of the entity at the other end of a link, and to detect when
it changes. GSMP is a hard state protocol. It is therefore important
to detect loss of contact between switch and controller, and to
detect any change of identity of switch or controller. No GSMP
messages other than those of the adjacency protocol may be sent
across the link until the adjacency protocol has achieved
synchronization.
10.1 Packet Format
All GSMP messages belonging to the adjacency protocol have the
following structure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
In the adjacency protocol the Version field is used for
version negotiation. In a SYN message the Version field
always contains the highest version understood by the
sender. A receiver receiving a SYN message with a version
higher than understood will ignore that message. A
receiver receiving a SYN message with a version lower than
its own highest version, but a version that it understands,
will reply with a SYNACK with the version from the received
SYN in its GSMP Version field. This defines the version of
the GSMP protocol to be used while the adjacency protocol
remains synchronized. All other messages will use the
agreed version in the Version field.
The version number for the version of the GSMP protocol
defined by this specification is Version = 2.
Message Type
The adjacency protocol is:
Message Type = 10
Timer
The Timer field is used to inform the receiver of the timer
value used in the adjacency protocol of the sender. The
timer specifies the nominal time between periodic adjacency
protocol messages. It is a constant for the duration of a
GSMP session. The timer field is specified in units of
100ms.
M-Flag
The M-Flag is used in the SYN message to indicate whether
the sender is a master or a slave. If the M-Flag is set in
the SYN message, the sender is a master. If zero, the
sender is a slave. The GSMP protocol is asymmetric, the
controller being the master and the switch being the slave.
The M-Flag prevents a master from synchronizing with
another master, or a slave with another slave. If a slave
receives a SYN message with a zero M-Flag, it must ignore
that SYN message. If a master receives a SYN message with
the M-Flag set, it must ignore that SYN message. In all
other messages the M-Flag is not used.
Code
Field specifies the function of the message. Four Codes are
defined for the adjacency protocol:
SYN: Code = 1
SYNACK: Code = 2
ACK: Code = 3
RSTACK: Code = 4.
Sender Name
For the SYN, SYNACK, and ACK messages, is the name of the
entity sending the message. The Sender Name is a 48-bit
quantity that is unique within the operational context of
the device. A 48-bit IEEE 802 MAC address, if available,
may be used for the Sender Name. If the Ethernet
encapsulation is used the Sender Name must be the Source
Address from the MAC header. For the RSTACK message, the
Sender Name field is set to the value of the Receiver Name
field from the incoming message that caused the RSTACK
message to be generated.
Receiver Name
For the SYN, SYNACK, and ACK messages, is the name of the
entity that the sender of the message believes is at the
far end of the link. If the sender of the message does not
know the name of the entity at the far end of the link,
this field should be set to zero. For the RSTACK message,
the Receiver Name field is set to the value of the Sender
Name field from the incoming message that caused the RSTACK
message to be generated.
Sender Port
For the SYN, SYNACK, and ACK messages, is the local port
number of the link across which the message is being sent.
For the RSTACK message, the Sender Port field is set to the
value of the Receiver Port field from the incoming message
that caused the RSTACK message to be generated.
Receiver Port
For the SYN, SYNACK, and ACK messages, is what the sender
believes is the local port number for the link, allocated
by the entity at the far end of the link. If the sender of
the message does not know the port number at the far end of
the link, this field should be set to zero. For the RSTACK
message, the Receiver Port field is set to the value of the
Sender Port field from the incoming message that caused the
RSTACK message to be generated.
Sender Instance
For the SYN, SYNACK, and ACK messages, is the sender's
instance number for the link. It is used to detect when the
link comes back up after going down or when the identity of
the entity at the other end of the link changes. The
instance number is a 32-bit number that is guaranteed to be
unique within the recent past and to change when the link
or node comes back up after going down. Zero is not a valid
instance number. For the RSTACK message, the Sender
Instance field is set to the value of the Receiver Instance
field from the incoming message that caused the RSTACK
message to be generated.
Receiver Instance
For the SYN, SYNACK, and ACK messages, is what the sender
believes is the current instance number for the link,
allocated by the entity at the far end of the link. If the
sender of the message does not know the current instance
number at the far end of the link, this field should be set
to zero. For the RSTACK message, the Receiver Instance
field is set to the value of the Sender Instance field from
the incoming message that caused the RSTACK message to be
generated.
10.2 Procedure
The adjacency protocol is described by the following rules and state
tables.
The rules and state tables use the following operations:
o The "Update Peer Verifier" operation is defined as storing the
values of the Sender Instance, Sender Port, and Sender Name fields
from a SYN or SYNACK message received from the entity at the far
end of the link.
o The procedure "Reset the link" is defined as:
1. Generate a new instance number for the link
2. Delete the peer verifier (set to zero the values of Sender
Instance, Sender Port, and Sender Name previously stored by
the Update Peer Verifier operation)
3. Send a SYN message
4. Enter the SYNSENT state.
o The state tables use the following Boolean terms and operators:
A The Sender Instance in the incoming message matches the
value stored from a previous message by the "Update Peer
Verifier" operation.
B The Sender Instance, Sender Port, and Sender Name fields in
the incoming message match the values stored from a
previous message by the "Update Peer Verifier" operation.
C The Receiver Instance, Receiver Port, and Receiver Name
fields in the incoming message match the values of the
Sender Instance, Sender Port, and Sender Name currently
sent in outgoing SYN, SYNACK, and ACK messages.
"&&" Represents the logical AND operation
"||" Represents the logical OR operation
"!" Represents the logical negation (NOT) operation.
o A timer is required for the periodic generation of SYN, SYNACK,
and ACK messages. The value of the timer is announced in the Timer
field. The period of the timer is unspecified but a value of one
second is suggested.
There are two independent events: the timer expires, and a packet
arrives. The processing rules for these events are:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives:
If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link
Else Discard the message.
If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following State Tables.
If incoming message is any other GSMP message and state !=
ESTAB:
Discard incoming message.
If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be
sent within any time period of length defined by the
timer.
o State synchronization across a link is considered to be achieved
when the protocol reaches the ESTAB state. All GSMP messages,
other than adjacency protocol messages, that are received before
synchronization is achieved will be discarded.
State Tables
State: SYNSENT
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+======================================================================+
State: SYNRCVD
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD |
+======================================================================+
State: ESTAB
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 2) | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 3) | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+======================================================================+
Note 2: No more than two ACKs should be sent within any time period
of length defined by the timer. Thus, one ACK must be sent every time
the timer expires. In addition, one further ACK may be sent between
timer expirations if the incoming message is a SYN or SYNACK. This
additional ACK allows the adjacency protocol to reach synchronization
more quickly.
Note 3: No more than one ACK should be sent within any time period of
length defined by the timer.
10.3 Loss of Synchronization
If after synchronization is achieved, no valid GSMP messages are
received in any period of time in excess of three times the value of
the Timer field announced in the incoming adjacency protocol
messages, loss of synchronization may be declared.
The preferred procedure for a switch to use when it looses
synchronization with its active controller is to attempt to establish
synchronization with (one of) its backup controller(s). However, in
this preferred approach, it must not reset its state until it
achieves synchronization with a backup controller. This means that
if, before achieving synchronization with a backup controller, it
regains synchronization with its original controller, it may continue
the original session (and cease attempting to establish
synchronization with a backup controller). If synchronization with
the original session is regained it is the responsibility of the
controller to ensure consistent state between the switch and
controller.
While the above is the preferred procedure, it is also the case that
the simplest procedure when declaring loss of synchronization with
the active controller is to reset the switch state, and start
searching for a controller. This simple procedure is legitimate.
11. Summary of Failure Response Codes
The following list gives a summary of the failure codes defined for
failure response messages:
1: Unspecified reason not covered by other failure codes.
2: Invalid request message.
3: The specified request is not implemented on this switch.
4: Invalid Port Session Number.
5: One or more of the specified ports does not exist.
6: One or more of the specified ports is down.
7: Unused. (This failure code has been replaced by failure codes
18--21.)
8: The specified connection does not exist.
9: The specified branch does not exist.
10: A branch belonging to the specified point-to-multipoint
connection is already established on the specified output
port and the switch cannot support more than a single
branch of any point-to-multipoint connection on the same
output port.
11: The limit on the maximum number of point-to-multipoint
connections that the switch can support has been reached.
12: The limit on the maximum number of branches that the
specified point-to-multipoint connection can support has
been reached.
13: Unable to assign the requested VPI/VCI value to the requested
branch on the specified point-to-multipoint connection.
14: General problem related to the manner in which point-to-
multipoint is supported by the switch.
15: Out of resources (e.g. memory exhausted, etc.).
16: Failure specific to the particular message type. (The meaning
of this failure code depends upon the Message Type. It is
defined within the description of any message that uses
it.)
17: Cannot label each output branch of a point-to-multipoint tree
with a different label.
18: One or more of the specified input VPIs is invalid.
19: One or more of the specified input VCIs is invalid.
20: One or more of the specified output VPIs is invalid.
21: One or more of the specified output VCIs is invalid.
22: Invalid Class of Service field in a Connection Management
message.
23: Insufficient resources for QoS Profile.
24: Virtual path switching is not supported on this input port.
25: Point-to-multipoint virtual path connections are not
supported on either the requested input port or the
requested output port.
26: Attempt to add a virtual path connection branch to an
existing virtual channel connection.
27: Attempt to add a virtual channel connection branch to an
existing virtual path connection.
28: Only point-to-point bidirectional connections may be
established.
29: Cannot support requested VPI range.
30: Cannot support requested VCI range on all requested VPIs.
31: The transmit cell rate of this output port cannot be changed.
32: Requested transmit cell rate out of range for this output
port.
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
12. Summary of Message Set
The following table gives a summary of the messages defined in this
version of the specification. It also indicates which messages must
be supported in a minimal implementation of the protocol. Those
messages marked as "Required" must be supported by the switch for an
implementation to be considered to conform to this specification.
(While the controller should also implement those messages marked
"Required," conformance cannot be tested for the controller due to
the Master-Slave nature of the protocol.)
Message Name Message Type Status
Connection Management Messages
Add Branch VCC....................16 Required
VPC....................26
Delete Tree.......................18
Delete All........................20
Delete Branches...................17 Required
Move Branch VCC...................22
VPC...................27
Port Management Messages
Port Management...................32 Required
Label Range.......................33
State and Statistics Messages
Connection Activity...............48
Port Statistics...................49 Required
Connection Statistics.............50
QoS Class Statistics..............51
Report Connection State...........52
Configuration Messages
Switch Configuration..............64 Required
Port Configuration................65 Required
All Ports Configuration...........66 Required
Event Messages
Port Up...........................80
Port Down.........................81
Invalid VPI/VCI...................82
New Port..........................83
Dead Port.........................84
Quality of Service Messages
QoS Configuration.................96
Scheduler Establishment...........97
QoS Class Establishment...........98
QoS Release.......................99
QoS Connection Management VCC....100
VPC....101
Adjacency Protocol....................10 Required
REFERENCES
[af-tm-0056] ATM Forum Traffic Management Specification 4.0, af-tm-
0056.000, April 1996.
[I.361] "B-ISDN ATM Layer Specification," International
Telecommunication Union, ITU-T Recommendation I.361,
Mar. 1993.
[I.363] "B-ISDN ATM Adaptation Layer (AAL) Specification,"
International Telecommunication Union, ITU-T
Recommendation I.363, Mar. 1993.
[IpsilonMIB] Ipsilon IP Switch MIB,
http://www.ipsilon.com/products/ips.mib
[Partridge] C. Partridge, "Gigabit Networking," Addison-Wesley,
1994.
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2,
RFC1700, October 1994.
[RFC1987] Newman, P, Edwards, W., hinden, R., Hoffman, E. Ching
Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General
Switch Management Protocol Specification," Version 1.1,
RFC1987, August 1996.
SECURITY CONSIDERATIONS
Physical security on the control link connecting the controller to
the switch is assumed. Security issues are not discussed in this
document.
AUTHORS' ADDRESSES
Peter Newman Phone: +1 (408) 990 2003
Nokia EMail: pn@ipsilon.com
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334
Sprint EMail: texas@sprintcorp.com
Robert M. Hinden Phone: +1 (408) 990 2004
Nokia EMail: hinden@ipsilon.com
Eric Hoffman Phone: +1 (408) 990 2010
Nokia EMail: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (408) 873 2688
Coppercom EMail: fong@coppercom.com
Tom Lyon Phone: +1 (408) 990 2001
Nokia EMail: pugs@ipsilon.com
Greg Minshall Phone: +1 (650) 237 3164
Fiberlane Communications EMail: minshall@fiberlane.com
Nokia (Sunnyvale) is located at:
232 Java Drive
Sunnyvale, CA 94089
USA
Sprint is located at:
Sprint
Sprint Technology Services - Long Distance Division
9300 Metcalf Avenue
Mailstop KSOPKB0802
Overland Park, KS 66212-6333
USA
Fiberlane Communications is located at:
1399 Charleston Road
Mountain View, CA 94043
USA
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.