RFC 3292
General Switch Management Protocol (GSMP) V3
Pages: 137
Proposed Standard
Proposed Standard
Part 5 of 5 – Pages 100 to 137
10.4 Service Definitions
This section sets forth the definition of Services. The following Service Identifiers are defined: ID Service Type 1 CBR= 1 2 rt-VBR.1 3 rt-VBR.2 4 rt-VBR.3 5 nrt-VBR.1 6 nrt-VBR.2 7 nrt-VBR.3 8 UBR.1 9 UBR.2 10-11 Reserved 12 GFR.1 13 GFR.2 14-19 Reserved 20 Int-Serv Controlled Load
21-24 Reserved
25 MPLS CR-LDP QoS
26-29 Reserved
30 Frame Relay Service
31-49 Reserved
50-69 Reserved GMPLS
70-65535 Reserved
Each Service will be defined in its own subsection. Each Service
definition includes the following definitions:
Service Identifier
The reference number used to identify the Service in GSMP
messages.
Service Characteristics
A definition of the Service.
Traffic Parameters
A definition of the Traffic Parameters used in connection
management messages.
QoS Parameters
A definition of the QoS Parameters that are included in the
Capability Set for instances of the Service.
Traffic Controls
A definition of the Traffic Controls that may be supported by
an instance of the Service.
Descriptive text is avoided wherever possible in order to minimise
any possibility of semantic conflict with the Original
Specifications.
10.4.1 ATM Forum Service Categories
10.4.1.1 CBR
Service Identifier:
CBR.1 - Service ID = 1
Service Characteristics:
Equivalent to ATM Forum CBR.1 Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
QoS Parameters:
- Cell Loss Ratio
- Maximum Cell Transfer Delay
- Peak-to-peak Cell Delay Variation
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
Variation Tolerance
- (D) Packet Discard
10.4.1.2 rt-VBR
Service Identifier:
rt-VBR.1 - Service ID = 2
rt-VBR.2 - Service ID = 3
rt-VBR.3 - Service ID = 4
Service Characteristics:
Equivalent to ATM Forum rt-VBR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Sustainable Cell Rate
- Maximum Burst Size
QoS Parameters:
- Cell Loss Ratio
- Maximum Cell Transfer Delay
- Peak-to-peak Cell Delay Variation
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
Variation Tolerance
- (S) Egress Traffic Shaping to the Sustainable Cell Rate and
Maximum Burst Size
- (P) Packet Discard
- (V) VC Merge
10.4.1.3 nrt-VBR
Service Identifier: nrt-VBR.1 - Service ID = 5 nrt-VBR.2 - Service ID = 6 nrt-VBR.3 - Service ID = 7 Service Characteristics: Equivalent to ATM Forum nrt-VBR Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance - Sustainable Cell Rate - Maximum Burst Size QoS Parameter: - Cell Loss Ratio Traffic Controls: - (U) Usage Parameter Control - (I) Ingress Traffic Shaping to the Peak Cell Rate - (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance - (S) Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size - (P) Packet Discard - (V) VC Merge10.4.1.4 UBR
Service Identifier: UBR.1 - Service ID = 8 UBR.2 - Service ID = 9 Service Characteristics: Equivalent to ATM Forum UBR Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance QoS Parameter: None Traffic Controls: - (U) Usage Parameter Control - (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
Variation Tolerance
- (P) Packet Discard
- (V) VC Merge
10.4.1.5 ABR
ABR is not supported in this version of GSMP.
10.4.1.6 GFR
Service Identifier:
GFR.1 - Service ID = 12
GFR.2 - Service ID = 13
Service Characteristics:
Equivalent to ATM Forum GFR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Minimum Cell Rate
- Maximum Burst Size
- Maximum Frame Size
QoS Parameter:
- Cell Loss Ratio
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
Variation Tolerance
- (V) VC Merge
10.4.2 Integrated Services
10.4.2.1 Controlled Load
Service Identifier:
Int-Serv Controlled Load - Service ID = 20
Service Characteristics:
See [9].
Traffic Parameters:
- Token bucket rate (r)
- Token bucket depth (b)
- Peak rate (p)
- Minimum policed unit (m)
- Maximum packet size (M)
QoS Parameter:
None.
Traffic Controls:
None.
10.4.3 MPLS CR-LDP
Service Identifier:
MPLS CR-LDP QoS - Service ID = 25
Service Characteristics:
See [10].
Traffic Parameters:
- Peak Data Rate
- Peak Burst Size
- Committed Data Rate
- Committed Burst Size
- Excess Burst Size
- Weight
QoS Parameter:
- Frequency
Traffic Controls:
None currently defined.
10.4.4 Frame Relay
Service Identifier:
Frame Relay Service - Service ID = 30
Service Characteristics:
Equivalent to Frame Relay Bearer Service, see [11].
Traffic Parameters:
- Committed Information Rate
- Committed Burst Rate
- Excess Burst Rate
QoS Parameters:
None.
Traffic Controls:
- Usage Parameter Control
- Egress Traffic Shaping to the Committed Information Rate and
Committed Burst Size
10.4.5 DiffServ
DiffServ is not supported in this version of GSMP.
10.5 Format and encoding of the Traffic Parameters
Connection management messages that use the GSMP Service Model (i.e.,
those that have IQS or OQS set to 0b10) include the Traffic
Parameters Block that specifies the Traffic Parameter values of a
connection. The required Traffic Parameters of a given Service are
given in Section 10.4. The format and encoding of these parameters
are given below.
10.5.1 Traffic Parameters for ATM Forum Services
The Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Sustainable Cell Rate
- Maximum Burst Size
- Minimum Cell Rate
- Maximum Frame Size
are defined in [8]. These Parameters are encoded as 24-bit unsigned
integers. Peak Cell Rate, Sustainable Cell Rate, and Minimum Cell
Rate are in units of cells per second. Cell Delay Variation
Tolerance is in units of microseconds. Maximum Burst Size and
Maximum Frame Size are in units of cells. In GSMP messages, the
individual Traffic Parameters are encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| 24 bit unsigned integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Parameters Block in connection management
messages depends on the Service. It is a sequence of the 32 bit
words (as shown above) corresponding to the Traffic Parameters as
specified in the Service Definitions given in Section 10.4.1 in the
order given there.
10.5.2 Traffic Parameters for Int-Serv Controlled Load Service
The Traffic Parameters:
- Token bucket rate (r)
- Token bucket size (b)
- Peak rate (p)
are defined in [9]. They are encoded as 32-bit IEEE single-precision
floating point numbers. The Traffic Parameters Token bucket rate (r)
and Peak rate (p) are in units of bytes per seconds. The Traffic
Parameter Token bucket size (b) is in units of bytes.
The Traffic Parameters:
- Minimum policed unit (m)
- Maximum packet size (M)
are defined in [9]. They are encoded as 32 integer in units of
bytes.
The Traffic Parameters Block for the Int-Serv Controlled Load Service
is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token bucket rate (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token bucket size (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak rate (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum packet size (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10.5.3 Traffic Parameters for CRLDP Service
The Traffic Parameters:
- Peak Data Rate
- Peak Burst Size
- Committed Data Rate
- Committed Burst Size
- Excess Burst Size
are defined in [10] to be encoded as a 32-bit IEEE single-precision
floating point number. A value of positive infinity is represented
as an IEEE single-precision floating-point number with an exponent of
all ones (255) and a sign and mantissa of all zeros. The values Peak
Data Rate and Committed Data Rate are in units of bytes per second.
The values Peak Burst Size, Committed Burst Size and Excess Burst
Size are in units of bytes.
The Traffic Parameter
- Weight
is defined in [10] to be an 8-bit unsigned integer indicating the
weight of the CRLSP. Valid weight values are from 1 to 255. The
value 0 means that weight is not applicable for the CRLSP.
The Traffic Parameters Block for the CRLDP Service is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x x x x x x x x x| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10.5.4 Traffic Parameters for Frame Relay Service
The Traffic Parameters:
- Committed Information Rate
- Committed Burst Size
- Excess Burst Size
are defined in [11]. Format and encoding of these parameters for
frame relay signalling messages are defined in [12]. (Note than in
[12] the Committed Information Rate is called "Throughput".) GSMP
uses the encoding defined in [12] but uses a different format.
The format of the Traffic Parameters Block for Frame Relay Service is
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x x x x| CIR Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x| CBS Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x| EBS Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mag
This field is an unsigned integer in the range from 0 to 6.
The value 7 is not allowed. Mag is the decimal exponent for
the adjacent multiplier field (which itself functions as a
mantissa).
CIR Multiplier
This field is an unsigned integer. It functions as the
mantissa of the Committed Information Rate Traffic Parameter.
CBS Multiplier
EBS Multiplier
These fields are unsigned integers. They function as the
mantissas of the Committed Burst Size and Excess Burst Size
Traffic Parameters respectively.
The Traffic Parameter Values are related to their encoding in GSMP
messages as follows:
Committed Information Rate = 10^(Mag) * (CIR Multiplier)
Committed Burst Size = 10^(Mag) * (CBS Multiplier)
Excess Burst Size = 10^(Mag) * (EBS Multiplier)
10.6 Traffic Controls (TC) Flags
The TC Flags field in Add Branch messages for connections using the
Service Model are set by the controller to indicate that specific
traffic controls are requested for the requested connection. The TC
Flags field is shown below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|D|I|E|S|V|P|x|
+-+-+-+-+-+-+-+-+
U: Usage Parameter Control
When set, this flag indicates that Usage Parameter Control
is requested.
D: Packet Discard
When set, this flag indicates that Packet Discard is
requested.
I: Ingress Shaping
When set, this flag indicates the availability of Ingress
Traffic Shaping to the Peak Rate and Delay Variation
Tolerance is requested.
E: Egress Shaping, Peak Rate
When set, this flag indicates that Egress Shaping to the
Peak Rate and Delay Variation Tolerance is requested.
S: Egress Traffic Shaping, Sustainable Rate
When set, this flag indicates that Egress Traffic Shaping to
the Sustainable Rate and Maximum Burst Size is requested.
V: VC Merge
When set, this flag indicates that ATM Virtual Channel Merge
(i.e., multipoint to point ATM switching with a traffic
control to avoid AAL5 PDU interleaving) is requested.
P: Port
When set indicates that traffic block pertains to Ingress
Port.
x: Reserved
The controller may set (to one) the flag corresponding to the
requested Traffic Control if the corresponding Traffic Control has
been indicated in the Service Configuration response message (Section
8.4) as available for application to connections that use the
requested Capability Set on a per connection basis. (The requested
Capability Set is indicated by the Capability Set ID the least
significant byte of the Service Selector field of the Add Branch
message.) If the Traffic Control has been indicated in the Service
Configuration response message as either not available in the
Capability Set or applied to all connections that use the Capability
Set then the controller sets the flag to zero and the switch ignores
the flag.
11. Adjacency Protocol
The adjacency protocol is used to synchronise 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
synchronisation.
11.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | PFlag | Sender Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Receiver Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version In the adjacency protocol the Version field is used for version negotiation. The version negotiation is performed before synchronisation is achieved. 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 synchronised. 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 = 3. 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 synchronising 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.
PType
PType is used to specify if partitions are used and how the
Partition ID is negotiated.
Type of partition being requested.
0 No Partition
1 Fixed Partition Request
2 Fixed Partition Assigned
PFlag
Used to indicate the type of partition request.
1 - New Adjacency.
In the case of a new adjacency, the state of the
switch will be reset.
2 - Recovered Adjacency.
In the case of a recovered adjacency, the state of
the switch will remain, and the Switch Controller
will be responsible for confirming that the state
of the switch matches the desired state.
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
24-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.
Partition ID
Field used to associate the message with a specific switch
partition.
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.
11.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, Sender Name and
Partition ID 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, Sender Name and Partition
ID 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, Receiver Name and
Partition ID fields in the incoming message match the values
of the Sender Instance, Sender Port, Sender Name and
Partition ID 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 synchronisation 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
synchronisation is achieved, will be discarded.
11.2.1 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 synchronisation more quickly.
Note 3: No more than one ACK should be sent within any time
period of length defined by the timer.
11.3 Partition Information State
Each instance of a [switch controller-switch partition] pair will
need to establish adjacency synchronisation independently.
Part of the process of establishing synchronisation when using
partition will be to establish the assignment of partition
identifiers. The following scenarios are provided for:
- A controller can request a specific partition ID by setting the
PType to Fixed Partition Request.
- A controller can let the switch decide whether it wants to
assign a fixed partition ID or not, by setting the PType to No
Partition.
- A switch can assign the specific Partition ID to the session by
setting the PType to Fixed Partition Assigned. A switch can
specify that no partitions are handled in the session by
setting the PType to No Partition.
The assignment is determined by the following behaviour:
- An adjacency message from a controller with PType = 1 and
Code = SYN SHOULD be treated as a partition request.
- An adjacency message from a switch with PType = 2 and
Code = SYN SHOULD be treated as a partition assignment.
- An adjacency message from a controller or a switch with
PType = 2 and Code = (SYNACK || ACK) SHOULD be treated as a
success response, the partition is assigned.
- An adjacency message from a controller with PType = 0 and
Code = SYN indicates that the controller has not specified if
it requests partitions or not.
- An adjacency message from a switch with PType = 0 and
Code = SYN indicates that the switch does not support
partitions.
- An adjacency message from a controller or a switch with
PType = 0 and Code = (SYNACK || ACK) indicates that the session
does not support partitions.
- An adjacency message from a controller or a switch with
PType = (1 || 2) and Code = RSTACK indicates that requested
Partition ID is unavailable.
- An adjacency message from a controller or a switch with
PType = 0 and Code = RSTACK indicates that an unidentified
error has occurred. The session SHOULD be reset.
All other combinations of PType and Code are undefined in this
version of GSMP.
11.4 Loss of Synchronisation
If after synchronisation 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 synchronisation may be declared.
While re-establishing synchronisation with a controller, a switch
SHOULD maintain its connection state, deferring the decision about
resetting the state until after synchronisation is re-established.
Once synchronisation is re-established the decision about resetting
the connection state SHOULD be made on the following basis:
- If PFLAG = 1, then a new adjacency has been established and the
state SHOULD be reset
- If PFLAG = 2, then adjacency has been re-established and the
connection state SHOULD be retained. Verification that
controller and connection state are the same is the
responsibility of the controller.
11.5 Multiple Controllers per switch partition
Multiple switch controllers may jointly control a single switch
partition. The controllers may control a switch partition either in
a primary/standby fashion or as part of multiple controllers
providing load-sharing for the same partition. It is the
responsibility of the controllers to co-ordinate their interactions
with the switch partition. In order to assist the controllers in tracking multiple controller adjacencies to a single switch partition, the Adjacency Update message is used to inform a controller that there are other controllers interacting with the same partition. It should be noted that the GSMP does not include features that allow the switch to co-ordinate cache synchronization information among controllers. The switch partition will service each command it receives in turn as if it were interacting with a single controller. Controller implementations without controller entity synchronisation SHOULD NOT use multiple controllers with a single switch partition.11.5.1 Multiple Controller Adjacency Process
The first adjacency for a specific partition is determined by the procedures described in section 11.2 and an Adjacency Update message will be sent. The next adjacencies to the partition are identified by a new partition request with the same Partition ID as the first one but with the different Sender Name. Upon establishing adjacency the Adjacency count will be increased and an Adjacency Update message will be sent. When adjacency between one partition and a controller is lost, the adjacency count will be decremented and an Adjacency Update message will be sent. Example: A switch partition has never been used. When the first controller (A) achieves adjacency, an adjacency count will be initiated and (A) will get an Adjacency Update message about itself with Code field = 1. Since (A) receives an adjacency count of 1 this indicates that it is the only controller for that partition. When a second adjacency (B), using the same Partition ID, achieves adjacency, the adjacency counter will be increased by 1. Both (A) and (B) will receive an Adjacency Update message indicating an adjacency count of 2 in the Code field. Since the count is greater than 1, this will indicate to both (A) and (B) that there is another controller interacting with the switch; identification of the other controller will not be provided by GSMP, but will be the responsibility of the controllers. If (A) looses adjacency, the adjacency count will be decreased and an Adjacency Update message will be sent to (B) indicating an adjacency count of 1 in the Code field. If (B) leaves as well, the partition is regarded as idle and the adjacency count may be reset.
12. Failure Response Codes
12.1 Description of Failure and Warning Response Messages
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. A warning response message is a success response (Result = 3) with the Code field specifying the warning code. The warning code specifies a warning that was generated during the successful operation. If the switch issues a failure response in reply to a request message, no change should be made to the state of the switch as a result of the message causing the failure. (For request messages that contain multiple requests, such as the Delete Branches message, the failure response message will specify which requests were successful and which failed. The successful requests may result in a changed state.) If the switch issues a failure response it MUST choose the most specific failure code according to the following precedence: - Invalid Message - General Message Failure - Specific Message Failure A failure response specified in the text defining the message type. - Connection Failures - Virtual Path Connection Failures - Multicast Failures - QoS Failures - General Failures - Warnings If multiple failures match in any of the following categories, the one that is listed first should be returned. The following failure response messages and failure and warning codes are defined:
Invalid Message
3: The specified request is not implemented on this switch.
The Message Type field specifies a message that is not
implemented on the switch or contains a value that is not
defined in the version of the protocol running in this
session of GSMP.
4: One or more of the specified ports does not exist.
At least one of the ports specified in the message is
invalid. A port is invalid if it does not exist or if it
has been removed from the switch.
5: Invalid Port Session Number.
The value given in the Port Session Number field does not
match the current Port Session Number for the specified
port.
7: Invalid Partition ID
The value given in the Partition ID field is not legal for
this partition.
General Message Failure
10: The meaning of this failure is dependent upon the
particular message type and is specified in the text
defining the message.
Specific Message Failure - A failure response that is only used by a
specific message type
- Failure response messages used by the Label Range message
40: Cannot support one or more requested label ranges.
41: Cannot support disjoint label ranges.
42: Specialised multipoint labels not supported.
- Failure response messages used by the Set Transmit Data Rate
function of the Port Management message
43: The transmit data rate of this output port cannot be changed.
44: Requested transmit data rate out of range for this output
port.
The transmit data rate of the requested output port can be
changed, but the value of the Transmit Data Rate field is
beyond the range of acceptable values.
- Failure response message of the Port Management message
45: Connection Replace mechanism not supported on switch.
The R-flag SHOULD be reset in the Response Port Management
message.
- Failure response message range reserved for the ARM extension
128-159: These failure response codes will be interpreted
according to definitions provided by the model
description.
Connection Failures
11: The specified connection does not exist.
An operation that expects a connection to be specified
cannot locate the specified connection. A connection is
specified by the input port and input label on which it
originates. An ATM virtual path connection is specified
by the input port and input VPI on which it originates.
12: The specified branch does not exist.
An operation that expects a branch of an existing
connection to be specified cannot locate the specified
branch. A branch of a connection is specified by the
connection it belongs to and the output port and output
label on which it departs. A branch of an ATM virtual
path connection is specified by the virtual path
connection it belongs to and the output port and output
VPI on which it departs.
13: One or more of the specified Input Labels is invalid.
14: One or more of the specified Output Labels is invalid.
15: Point-to-point bi-directional connection already exists.
The connection specified by the Input Port and Input Label
fields already exists, and the bi-directional Flag in the
Flags field is set.
16: Invalid Service Selector field in a Connection Management
message. The value of the Service Selector field is
invalid.
17: Insufficient resources for QoS Profile.
The resources requested by the QoS Profile in the Service
Selector field are not available.
18: Insufficient Resources.
Switch resources needed to establish a branch are not
available.
20: Reservation ID out of Range
The numerical value of Reservation ID is greater than the
value of Max Reservations (from the Switch Configuration
message).
21: Mismatched reservation ports
The value of Input Port differs from the input port
specified in the reservation or the value of Output Port
differs from the output port specified in the reservation.
22: Reservation ID in use
The value of Reservation ID matches that of an extant
Reservation.
23: Non-existent reservation ID
No reservation corresponding to Reservation ID exists.
36: Replace of connection is not activated on switch.
Only applicable for Add Branch messages. The Replace
Connection mechanism has not been activated on port by the
Port Management message.
37: Connection replacement mode cannot be combined with Bi-
directional or Multicast mode. The R flag MUST NOT be
used in conjunction with either the M flag or the B flag.
ATM Virtual Path Connections
24: ATM virtual path switching is not supported on this input
port.
25: Point-to-multipoint ATM virtual path connections are not
supported on either the requested input port or the
requested output port.
One or both of the requested input and output ports is
unable to support point-to-multipoint ATM virtual path
connections.
26: Attempt to add an ATM virtual path connection branch to an
existing virtual channel connection.
It is invalid to mix branches switched as virtual channel
connections with branches switched as ATM virtual path
connections on the same point-to-multipoint connection.
27: Attempt to add an ATM virtual channel connection branch to an
existing ATM virtual path connection.
It is invalid to mix branches switched as virtual channel
connections with branches switched as ATM virtual path
connections on the same point-to-multipoint connection.
28: ATM Virtual path switching is not supported on non-ATM ports.
One or both of the requested input and output ports is not
an ATM port. ATM virtual path switching is only supported
on ATM ports.
Multicast Failures
29: 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.
30: The limit on the maximum number of multicast connections that
the switch can support has been reached.
31: The limit on the maximum number of branches that the specified
multicast connection can support has been reached.
32: Cannot label each output branch of a point-to-multipoint tree
with a different label.
Some switch designs, require all output branches of a
point-to-multipoint connection to use the same value of
Label.
33: Cannot add multi-point branch to bi-directional connection.
It is an error to attempt to add an additional branch to
an existing connection with the bi-directional flag set.
34: Unable to assign the requested Label value to the requested
branch on the specified multicast connection.
Although the requested Labels are valid, the switch is
unable to support the request using the specified Label
values for some reason not covered by the above failure
responses. This message implies that a valid value of
Labels exists that the switch could support. For example,
some switch designs restrict the number of distinct Label
values available to a multicast connection. (Most switch
designs will not require this message.)
35: General problem related to the manner in which multicast is
supported by the switch.
Use this message if none of the more specific multicast
failure messages apply. (Most switch designs will not
require this message.)
QoS Failures
60-79: These failure response codes will be interpreted according
to definitions provided by the model description.
80: Switch does not support different QoS parameters for different
branches within a multipoint connection.
General Failures
2: Invalid request message.
There is an error in one of the fields of the message not
covered by a more specific failure message.
6: One or more of the specified ports is down.
A port is down if its Port Status is Unavailable.
Connection Management, Connection State, Port Management,
and Configuration operations are permitted on a port that
is Unavailable. Connection Activity and Statistics
operations are not permitted on a port that is Unavailable
and will generate this failure response. A Port
Management message specifying a Take Down function on a
port already in the Unavailable state will also generate
this failure response.
19: Out of resources.
The switch has exhausted a resource not covered by a more
specific failure message, for example, running out of
memory.
1: Unspecified reason not covered by other failure codes.
The failure message of last resort.
Warnings
46: One or more labels are still used in the previous Label Range.
12.2 Summary of Failure Response Codes and Warnings
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: One or more of the specified ports does not exist.
5: Invalid Port Session Number.
6: One or more of the specified ports is down.
7: Invalid Partition ID.
10: General message failure. (The meaning of this failure code
depends upon the Message Type. It is defined within the
description of any message that uses it.)
11: The specified connection does not exist.
12: The specified branch does not exist.
13: One or more of the specified Input Labels is invalid.
14: One or more of the specified Output Labels is invalid.
15: Point-to-point bi-directional connection already exists.
16: Invalid service selector field in a connection management
message.
17: Insufficient resources for QoS profile.
18: Insufficient resources.
19: Out of resources (e.g., memory exhausted, etc.).
20: Reservation ID out of Range
21: Mismatched reservation ports
22: Reservation ID in use
23: Non-existent reservation ID
24: ATM virtual path switching is not supported on this input
port.
25: Point-to-multipoint ATM virtual path connections are not
supported on either the requested input port or the
requested output port.
26: Attempt to add an ATM virtual path connection branch to an
existing virtual channel connection.
27: Attempt to add an ATM virtual channel connection branch to
an existing virtual path connection.
28: ATM Virtual Path switching is not supported on non-ATM
ports.
29: 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.
30: The limit on the maximum number of point-to-multipoint
connections that the switch can support has been
reached.
31: The limit on the maximum number of branches that the
specified point-to-multipoint connection can support has
been reached.
32: Cannot label each output branch of a point-to-multipoint
tree with a different label.
33: Cannot add multi-point branch to bi-directional
connection.
34: Unable to assign the requested Label value to the
requested branch on the specified point-to-multipoint
connection.
35: General problem related to the manner in which point-to-
multipoint is supported by the switch.
36: Replace of connection is not activated on switch.
37: Connection replacement mode cannot be combined with Bi-
directional or Multicast mode.
40: Cannot support one or more requested label ranges.
41: Cannot support disjoint label ranges.
42: Specialised multipoint labels not supported.
43: The transmit data rate of this output port cannot be
changed.
44: Requested transmit data rate out of range for this output
port.
45: Connection Replace mechanism not supported on switch.
46: Labels are still used in the existing Label Range.
60-79: Reserved for QoS failures.
80: Switch does not support different QoS parameters for
different branches within a multipoint connection.
128-159: Reserved for the ARM extensions.
13. Security Considerations
The security of GSMP's TCP/IP control channel has been addressed in
[15]. For all uses of GSMP over an IP network it is REQUIRED that
GSMP be run over TCP/IP using the security considerations discussed
in [15].
Appendix A Summary of Messages
Message Name Message Number Status Connection Management Messages Add Branch .......................16 ATM Specific - VPC.............26 Delete Tree.......................18 Verify Tree.......................19 Obsoleted Delete All Input..................20 Delete All Output.................21 Delete Branches...................17 Move Output Branch................22 ATM Specific - VPC............27 Move Input Branch.................23 ATM Specifc - VPC............28 Port Management Messages Port Management...................32 Label Range.......................33 State and Statistics Messages Connection Activity...............48 Port Statistics...................49 Connection Statistics.............50 QoS Class Statistics..............51 Reserved Report Connection State...........52 Configuration Messages Switch Configuration..............64 Port Configuration................65 All Ports Configuration...........66 Service Configuration.............67 Reservation Messages Reservation Request...............70 Delete Reservation................71 Delete All Reservations...........72 Event Messages Port Up...........................80 Port Down.........................81 Invalid Label.....................82 New Port..........................83 Dead Port.........................84
Abstract and Resource Model Extension Messages
Reserved..........................200-249
Adjacency Protocol....................10 Required
Appendix B IANA Considerations
Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" (RFC 2434 [19]), the following name
spaces are defined in GSMPv3.
- Message Type Name Space [Appendix A]
- Label Type Name Space [3.1.3]
- Result Name Space [3.1.1]
- Failure Response Message Name Space [3.1.4],[11]
- Adaptation Type Name Space [4.1]
- Model Type Name Space [8.1]
- Port Type Name Space [8.2]
- Service ID Name Space [10.4]
- Traffic Control Name Space [8.4]
- Event Flag Name Space [6.1]
B.1. Message Type Name Space
GSMPv3 divides the name space for Message Types into four ranges.
The following are the guidelines for managing these ranges.
- Message Types 0-99.
Message Types in this range are part of the GSMPv3 base
protocol. Message types in this range are allocated
through an IETF consensus action [19].
- Message Types 100-199.
Message Types in this range are Specification Required
[19]. Message Types using this range must be documented
in an RFC or other permanent and readily available
references.
- Message Types 200-249.
Message Types in this range are Specification Required
[19] and are intended for Abstract and Resource Model
Extension Messages. Message Types using this range must
be documented in an RFC or other permanent and readily
available references.
- Message Types 250-255.
Message Types in this range are reserved for vendor
private extensions and are the responsibility of
individual vendors. IANA management of this range of the
Message Type Name Space is unnecessary.
B.2. Label Type Name Space
GSMPv3 divides the name space for Label Types into three ranges. The
following are the guidelines for managing these ranges.
- Label Types 0x000-0xAFF.
Label Types in this range are part of the GSMPv3 base
protocol. Label Types in this range are allocated through
an IETF consensus action [19].
- Label Types 0xB00-0xEFF.
Label Types in this range are Specification Required [19].
Label Types using this range must be documented in an RFC
or other permanent and readily available reference.
- Label Types 0xF00-0xFFF.
Label Types in this range are reserved for vendor private
extensions and are the responsibility of individual
vendors. IANA management of this range of the Label Type
Name Space is unnecessary.
B.3. Result Name Space
The following is the guideline for managing the Result Name Space:
- Result values 0-255.
Result values in this range need an expert review, i.e.,
approval by a Designated Expert is required [19].
B.4. Failure Response Name Space
GSMPv3 divides the name space for Failure Responses into three
ranges. The following are the guidelines for managing these ranges:
- Failure Responses 0-59, 80-127, 160-255.
Failure responses in these ranges are part of the GSMPv3
base protocol. Failure Responses in these ranges are
allocated through an IETF consensus action [19].
- Failure Responses 60-79, 128-159.
Failure responses in these ranges are reserved for vendor
private extensions and are the responsibility of
individual vendors. IANA management of these ranges of
the Failure Response Name Space are unnecessary.
B.5. Adaptation Type Name Space
GSMPv3 divides the name space for Adaptation Types into two ranges.
The following are the guidelines for managing these ranges:
- Adaptation Type 0x000-0x2FF.
Adaptation Types in this range are part of the GSMPv3 base
protocol. Adaptation Types in this range are allocated
through an IETF consensus action [19].
- Adaptation Type 0x300-0xFFF.
Adaptation Types in this range are allocated by the first
come first served principle [19].
B.6. Model Type Name Space
GSMPv3 divides the name space for Model Types into three ranges. The
following are the guidelines for managing these ranges:
- Model Type 0.
Model Types in this range are part of the GSMPv3 base
protocol. Model Types in this range are allocated through
an IETF consensus action [19].
- Model Type 1-200.
Model Types in this range are Specification Required [19].
Message Types using this range must be documented in an
RFC or other permanent and readily available references.
- Model Type 201-255.
Model Types in this range are reserved for vendor private
extensions and are the responsibility of individual
vendors. IANA management of these ranges of the Model
Type Name Space are unnecessary.
B.7. Port Type Name Space
GSMPv3 divides the name space for Port Types into two ranges. The following are the guidelines for managing these ranges: - Port Type 0-127. Port Types in this range are part of the GSMPv3 base protocol. Port Types in this range are allocated through an IETF consensus action [19]. - Port Type 128-255. Port Types in this range are Specification Required [19]. Port Types using this range must be documented in an RFC or other permanent and readily available references.B.8. Service ID Name Space
GSMPv3 divides the name space for Service IDs into two ranges. The following are the guidelines for managing these ranges: - Service ID 0-1023. Service ID's in this range are part of the GSMPv3 base protocol. Service ID's in this range are allocated through an IETF consensus action [19]. - Service ID 1024-65535. Service ID's in this range are Specification Required [19]. Service ID's using this range must be documented in an RFC or other permanent and readily available references.B.9. Traffic Control Name Space
The following are the guidelines for managing Traffic Control Flags in GSMPv3: - All Traffic Control Flags are allocated through an expert review, i.e., approval by a Designated Expert [19].B.10. Event Flag Name Space
The following are the guidelines for managing Event Flags in GSMPv3: - All Event Flags are allocated through an expert review, i.e., approval by a Designated Expert [19]. The TCP port for establishing GSMP connections has been defined as 6068.
References
[1] "B-ISDN ATM Layer Specification", International Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999. [2] "B-ISDN ATM Adaptation Layer (AAL) Specification", International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993. [3] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, ITU-T, Recommendation I.363.5, Aug. 1996. [4] Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)", RFC 3295, June 2002. [5] IANA Assigned Port Numbers, http://www.iana.org [6] 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", RFC 1987, August 1996. [7] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998. [8] ATM Forum Technical Committee, "Traffic Management Specification Version 4.1", af-tm-0121.000, 1999. [9] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [10] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint- Based LSP Setup using LDP", RFC 3212, January 2002. [11] ITU-T Recommendation I.233 Frame Mode Bearer Services, ISDN frame relaying bearer services and ISDN switching bearer service, Nov. 1991. [12] ITU-T Recommendation Q.933, Integrated Services Digital Network (ISDN) Digital Subscriber Signaling System No. 1 (DSS 1) Signaling Specifications For Frame Mode Switched And Permanent Virtual Connection Control And Status Monitoring, 1995.
[13] ITU-T Recommendation Q.922, Integrated Services Digital Network (ISDN) Data Link Layer Specification For Frame Mode Bearer Services, 1992 [14] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [15] Worster, T., Doria, A. and J. Buerkle, "General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)", RFC 3293, June 2002. [16] Doria, A. and K. Sundell, "General Switch Management Protocol Applicability", RFC 3294, June 2002. [17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001. [18] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. [19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [21] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
Authors' Addresses
Avri Doria Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden Phone: +1 401 663 5024 EMail: avri@acm.org Fiffi Hellstrand Nortel Networks AB S:t Eriksgatan 115 A SE-113 85 Stockholm Sweden EMail: fiffi@nortelnetworks.com Kenneth Sundell Nortel Networks AB S:t Eriksgatan 115 A SE-113 85 Stockholm Sweden EMail: ksundell@nortelnetworks.com Tom Worster Phone: +1 617 247 2624 EMail: fsb@thefsb.org
Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.