format is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Server Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID
This field contains an identifier which identifies the
client/server protocol which is making use of SCSP for the given
message. The assignment of Protocol IDs for this field is given
over to IANA as described in Section C. Protocols with current
documents have the following defined values:
1 - ATMARP
2 - NHRP
3 - MARS
4 - DHCP
5 - LNNI
Server Group ID
This ID is uniquely identifies the instance of a given
client/server protocol for which servers are being synchronized.
Flags
The Flags field is message specific, and its use will be described
in the specific message format sections below.
Sender ID Len
This field holds the length in octets of the Sender ID.
Recvr ID Len
This field holds the length in octets of the Receiver ID.
Number of Records
This field contains the number of additional records associated
with the given message. The exact format of these records is
specific to the message and will be described for each message type
in the sections below.
Sender ID
This is an identifier assigned to the server which is sending the
given message. One possible assignment might be the protocol
address of the sending server.
Receiver ID
This is an identifier assigned to the server which is to receive
the given message. One possible assignment might be the protocol
address of the server which is to receive the given message.
B.2.0.2 Cache State Advertisement Summary Record (CSAS record)
CSAS records contain a summary of information contained in a cache
entry of a given client/server database which is being synchronized
through the use of SCSP. The summary includes enough information for
SCSP to look into the client/server database for the appropriate
database cache entry and then compare the "newness" of the summary
against the "newness" of the cached entry.
Note that CSAS records do not contain a Server Group ID (SGID) nor do
they contain a Protocol ID. These IDs are necessary to identify
which protocol and which instance of that protocol for which the
summary is applicable. These IDs are present in the mandatory common
part of each message.
Note also that the values of the Hop Count and Record Length fields
of a CSAS Record are dependent on whether the CSAS record exists as a
"stand-alone" record or whether the CSAS record is "embedded" in CSA
Record. This is further described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Count
This field represents the number of hops that the record may take
before being dropped. Thus, at each server that the record
traverses, the Hop Count is decremented. This field is set to 1
when the CSAS record is a "stand-alone" record (i.e., it is not
embedded within a CSA record) since summaries do not go beyond one
hop during the cache alignment process. If a CSAS record is
"embedded" within a CSA record then the Hop Count is set to an
administratively defined value which is almost certainly greater
than or equal to the the cardinality of the SG minus one. Note
that an exception to the previous rule occurs when the CSA Record
is carried within a CSU Request which was sent in response to a
solicitation (i.e., in response to a CSAS Record which was sent in
a CSUS message); in which case, the Hop Count SHOULD be set to 1.
Record Length
If the CSAS record is a "stand-alone" record then this value is
12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value
is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server
Protocol Specific Part for cache entry"). The size of the
Client/Server Protocol Specific Part may be obtained from the
client/server protocol specific document for the given Protocol ID.
Cache Key Len
Length of the Cache Key field in bytes.
Orig ID Len.
Length of the Originator ID field in bytes.
N
The "N" bit signifies that this CSAS Record is actually a Null
record. This bit is only used in a CSAS Record contained in a CSU
Request/Reply which is sent in response to a CSUS message. It is
possible that an LS may receive a solicitation for a CSA record
when the cache entry represented by the solicited CSA Record no
longer exists in the LS's cache (see Section 2.3 for details). In
this case, the LS copies the CSAS Record directly from the CSUS
message into the CSU Request, and the LS sets the N bit signifying
that the cache entry does not exist any longer. The DCS which
solicited the CSA record which no longer exists will still respond
with a CSU Reply. This bit is usually set to zero.
CSA Sequence Number
This field contains a sequence number that identifies the "newness"
of a CSA record instance being summarized. A "larger" sequence
number means a more recent advertisement. Thus, if the state of
part (or all) of a cache entry needs to be updated then the CSA
record advertising the new state MUST contain a CSA Sequence Number
which is larger than the one corresponding to the previous
advertisement. This number is assigned by the originator of the
CSA record. The CSA Sequence Number may be assigned by the
originating server or by the client which caused its server to
advertise its existence.
The CSA Sequence Number is a signed 32 bit number. Within the CSA
Sequence Number space, the number -2^31 (0x80000000) is reserved.
Thus, the usable portion of the CSA Sequence Number space for a
given Cache Key is between the numbers -2^31+1 (0x80000001) and
2^31-1 (0x7fffffff). An LS uses -2^31+1 the first time it
originates a CSA Record for a cache entry that it created. Each
time the cache entry is modified in some manner and when that
modification needs to be synchronized with the other servers in the
SG, the LS increments the CSA Sequence number associated with the
given Cache Key and uses that new CSA Sequence Number when
advertising the update. If it is ever the case that a given CSA
Sequence Number has reached 2^31-2 and the associated cache entry
has been modified such that an update must be sent to the rest of
the servers in the SG then the given cache entry MUST first be
purged from the SG by the LS by sending a CSA Record which causes
the cache entry to be removed from other servers and this CSA
Record carries a CSA Sequence Number of 2^31-1. The exact packet
format and mechanism by which a cache entry is purged is defined in
the appropriate protocol specific document. After the purging CSA
Record has been acknowledged by each DCS, an LS will then send a
new CSA Record carrying the updated information, and this new CSA
Record will carry a CSA Sequence Number of -2^31+1.
After a restart occurs and after the restarting LS's CAFSM has
achieved the Aligned state, if an update to an existing cache entry
needs to be synchronized or a new cache entry needs to be
synchronized then the ensuing CSA Record MUST contain a CSA
Sequence Number which is unique within the SG for the given OID and
Cache Key. The RECOMMENDED method of obtaining this number (unless
explicitly stated to the contrary in the protocol specific
document) is to set the CSA Sequence Number in the CSA Record to
the CSA Sequence Number associated with the existing cache entry
(if an out of date cache entry already exists and zero if not) plus
a configured constant. Note that the protocol specific document
may require that all cache entries containing the OID of the
restarting LS be purged prior to updating the cache entries; in
this case, the updating CSA Record will still contain a CSA
Sequence Number set to the CSA Sequence Number associated with the
previously existing cache entry plus a configured constant.
Cache Key
This is a database lookup key that uniquely identifies a piece of
data which the originator of a CSA Record wishes to synchronize
with its peers for a given "Protocol ID/Server Group ID" pair.
This key will generally be a small opaque byte string which SCSP
will associate with a given piece of data in a cache. Thus, for
example, an originator might assign a particular 4 byte string to
the binding of an IP address with that of an ATM address.
Generally speaking, the originating server of a CSA record is
responsible for generating a Cache Key for every element of data
that the the given server originates and which the server wishes to
synchronize with its peers in the SG.
Originator ID
This field contains an ID administratively assigned to the server
which is the originator of CSA Records.
B.2.1 Cache Alignment (CA)
The Cache Alignment (CA) message allows an LS to synchronize its
entire cache with that of the cache of its DCSs within a server
group. The CA message type code is 1. The CA message mandatory part
format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CA Sequence Number
A value which provides a unique identifier to aid in the sequencing
of the cache alignment process. A "larger" sequence number means a
more recent CA message. The slave server always copies the
sequence number from the master server's previous CA message into
its current CA message which it is sending and the the slave
acknowledges the master's CA message. Since the initial CA process
is lock-step, if the slave does not receive the same sequence
number which it previously received then the information in the
slave's previous CA message is implicitly acknowledged. Note that
there is a separate CA Sequence Number space associated with each
CAFSM.
Whenever it is necessary to (re)start cache alignment and the CAFSM
enters the Master/Slave Negotiation state, the CA Sequence Number
should be set to a value not previously seen by the DCS. One
possible scheme is to use the machine's time of day counter.
Mandatory Common Part
The mandatory common part is described in detail in Section
B.2.0.1. There are two fields in the mandatory common part whose
codings are specific to a given message type. These fields are the
"Number of Records" field and the "Flags" field.
Number of Records
The Number of Records field of the mandatory common part for the
CA message gives the number of CSAS Records appended to the CA
message mandatory part.
Flags
The Flags field of the mandatory common part for the CA message
has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
This bit is part of the negotiation process for the cache
alignment. When this bit is set then the sender of the CA
message is indicating that it wishes to lead the alignment
process. This bit is the "Master/Slave bit".
I
When set, this bit indicates that the sender of the CA message
believes that it is in a state where it is negotiating for the
status of master or slave. This bit is the "Initialization
bit".
O
This bit indicates that the sender of the CA message has more
CSAS records to send. This implies that the cache alignment
process must continue. This bit is the "mOre bit" despite its
dubious name.
All other fields of the mandatory common part are coded as
described in Section B.2.0.1.
CSAS record
The CA message appends CSAS records to the end of its mandatory
part. These CSAS records are NOT embedded in CSA records. See
Section B.2.0.2 for details on CSAS records.
B.2.2 Cache State Update Request (CSU Request)
The Cache State Update Request (CSU Request) message is used to
update the state of cache entries in servers which are directly
connected to the server sending the message. A CSU Request message
is sent from one server (the LS) to directly connected server (the
DCS) when the LS observes changes in the state of one or more cache
entries. An LS observes such a change in state by either receiving a
CSU request which causes an update to the LS's database or by
observing a change of state of a cached entry originated by the LS.
The change in state of a cache entry is noted in a CSU message by
appending a "Cache State Advertisement" (CSA) record to the end of
the mandatory part of the CSU Request as shown below.
The CSU Request message type code is 2. The CSU Request message
mandatory part format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory Common Part
The mandatory common part is described in detail in Section
B.2.0.1. There are two fields in the mandatory common part whose
codings are specific to a given message type. These fields are the
"Number of Records" field and the "Flags" field.
Number of Records
The Number of Records field of the mandatory common part for the
CSU Request message gives the number of CSA Records appended to
the CSU Request message mandatory part.
Flags
Currently, there are no flags defined for the Flags field of the
mandatory common part for the CSU Request message.
All other fields of the mandatory common part are coded as
described in Section B.2.0.1.
CSA Record
See Section B.2.2.1.
B.2.2.1 Cache State Advertisement Record (CSA record)
CSA records contain the information necessary to relate the current
state of a cache entry in an SG to the servers being synchronized.
CSA records contain a CSAS Record header and a client/server protocol
specific part. The CSAS Record includes enough information for SCSP
to look into the client/server database for the appropriate database
cache entry and then compare the "newness" of the summary against the
"newness" of the cached entry. If the information contained in the
CSA is more new than the cached entry of the receiving server then
the cached entry is updated accordingly with the contents of the CSA
Record. The client/server protocol specific part of the CSA Record
is documented separately for each such protocol. Examples of the
protocol specific parts for NHRP and ATMARP are shown in [8] and [9]
respectively.
The amount of information carried by a specific CSA record may exceed
the size of a link layer PDU. Hence, such CSA records MUST be
fragmented across a number of CSU Request messages. The method by
which this is done, is client/server protocol specific and is
documented in the appropriate protocol specific document.
The content of a CSA record 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client/Server Protocol Specific Part for cache entry ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CSAS Record
See Section B.2.0.2 for rules and format for filling out a CSAS
Record when it is "embedded" in a CSA Record.
Client/Server Protocol Specific Part for cache entry
This field contains the fields which are specific to the protocol
specific portion of SCSP processing. The particular set of fields
are defined in separate documents for each protocol user of SCSP.
The Protocol ID, which identifies which protocol is using SCSP in
the given packet, is located in the mandatory part of the message.
B.2.3 Cache State Update Reply (CSU Reply)
The Cache State Update Reply (CSU Reply) message is sent from a DCS
to an LS to acknowledge one or more CSA records which were received
in a CSU Request. Reception of a CSA record in a CSU Request is
acknowledged by including a CSAS record in the CSU Reply which
corresponds to the CSA record being acknowledged. The CSU Reply
message is the same in format as the CSU Request message except for
the following: the type code is 3, only CSAS Records (rather than CSA
records) are returned, and only those CSAS Records for which CSA
Records are being acknowledged are returned. This implies that a
given LS sending a CSU Request may not receive an acknowledgment in a
single CSU Reply for all the CSA Records included in the CSU Request.
B.2.4 Cache State Update Solicit Message (CSUS message)
This message allows one server (LS) to solicit the entirety of CSA
record data stored in the cache of a directly connected server (DCS).
The DCS responds with CSU Request messages containing the appropriate
CSA records. The CSUS message type code is 4. The CSUS message
format is the same as that of the CSU Reply message. CSUS messages
solicit CSU Requests from only one server (the one identified by the
Receiver ID in the Mandatory Part of the message).
B.2.5 Hello:
The Hello message is used to check connectivity between the sending
server (the LS) and one of its directly connected neighbor servers
(the DCSs). The Hello message type code is 5. The Hello message
mandatory part format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | DeadFactor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Family ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval
The hello interval advertises the time between sending of
consecutive Hello Messages. If the LS does not receive a Hello
message from the DCS (which contains the LSID as a Receiver ID)
within the HelloInterval advertised by the DCS then the DCS's Hello
is considered to be late. Also, the LS MUST send its own Hello
message to a DCS within the HelloInterval which it advertised to
the DCS in the LS's previous Hello message to that DCS (otherwise
the DCS would consider the LS's Hello to be late).
DeadFactor
This is a multiplier to the HelloInterval. If an LS does not
receive a Hello message which contains the LS's LSID as a Receiver
ID within the interval HelloInterval*DeadFactor from a given DCS,
which advertised the HelloInterval and DeadFactor in a previous
Hello message, then the LS MUST consider the DCS to be stalled; at
this point, one of two things MUST happen: 1) if the LS has
received any Hello messages from the DCS during this time then the
LS transitions the corresponding HFSM to the Unidirectional State;
otherwise, 2) the LS transitions the corresponding HFSM to the
Waiting State.
Family ID
This is an opaque bit string which is used to refer to an aggregate
of Protocol ID/SGID pairs. Only a single HFSM is run for all
Protocol ID/SGID pairs assigned to a Family ID. Thus, there is a
one to many mapping between the single HFSM and the CAFSMs
corresponding to each of the Protocol ID/SGID pairs. This might
have the net effect of substantially reducing HFSM maintenance
traffic. See the protocol specific SCSP documents for further
details.
Mandatory Common Part
The mandatory common part is described in detail in Section
B.2.0.1. There are two fields in the mandatory common part whose
codings are specific to a given message type. These fields are the
"Number of Records" field and the "Flags" field.
Number of Records
The Number of Records field of the mandatory common part for the
Hello message contains the number of "Additional Receiver ID"
records which are included in the Hello. Additional Receiver ID
records contain a length field and a Receiver ID field. Note
that the count in "Number of Records" does NOT include the
Receiver ID which is included in the Mandatory Common Part.
Flags
Currently, there are no flags defined for the Flags field of the
mandatory common part for the Hello message.
All other fields of the mandatory common part are coded as
described in Section B.2.0.1.
Additional Receiver ID Record
This record contains a length field followed by a Receiver ID.
Since it is conceivable that the length of a given Receiver ID may
vary even within an SG, each additional Receiver ID heard (beyond
the first one) will have both its length in bytes and value encoded
in an "Additional Receiver ID Record". Receiver IDs are IDs of a
DCS from which the LS has heard a recent Hello (i.e., within
DeadFactor*HelloInterval as advertised by the DCS in a previous
Hello message).
The format for this record 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec ID Len | Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the LS has not heard from any DCS then the LS sets the Hello
message fields as follows: Recvr ID Len is set to zero and no
storage is allocated for the Receiver ID in the Common Mandatory
Part, "Number of Records" is set to zero, and no storage is
allocated for "Additional Receiver ID Records".
If the LS has heard from exactly one DCS then the LS sets the Hello
message fields as follows: the Receiver ID of the DCS which was
heard and the length of that Receiver ID are encoded in the Common
Mandatory Part, "Number of Records" is set to zero, and no storage is
allocated for "Additional Receiver ID Records".
If the LS has heard from two or more DCSs then the LS sets the Hello
message fields as follows: the Receiver ID of the first DCS which
was heard and the length of that Receiver ID are encoded in the
Common Mandatory Part, "Number of Records" is set to the number of
"Additional" DCSs heard, and for each additional DCS an "Additional
Receiver ID Record" is formed and appended to the end of the Hello
message.
B.3 Extensions Part
The Extensions Part, if present, carries one or more extensions in
{Type, Length, Value} triplets.
Extensions 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The extension type code (see below).
Length
The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header
and a length of zero).
When extensions exist, the extensions part is terminated by the End
of Extensions extension, having Type = 0 and Length = 0.
Extensions may occur in any order but any particular extension type
may occur only once in an SCSP packet. An LS MUST NOT change the
order of extensions.
B.3.0 The End Of Extensions
Type = 0
Length = 0
When extensions exist, the extensions part is terminated by the End
Of Extensions extension.
B.3.1 SCSP Authentication Extension
Type = 1 Length = variable
The SCSP Authentication Extension is carried in SCSP packets to
convey the authentication information between an LS and a DCS in the
same SG.
Authentication is done pairwise on an LS to DCS basis; i.e., the
authentication extension is generated at each LS. If a received
packet fails the authentication test then an "abnormal event" has
occurred. The packet is discarded and this event is logged.
The presence or absence of authentication is a local matter.
B.3.1.1 Header Format
The authentication header has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a
table that maintains the keys and other information such as hash
algorithm. LS and DCS communicate either off-line using manual keying
or online using a key management protocol to populate this table. The
receiving SCSP entity always allocates the SPI and the parameters
associated with it.
The authentication data field contains the MAC (Message
Authentication Code) calculated over the entire SCSP payload. The
length of this field is dependent on the hash algorithm used to
calculate the MAC.
B.3.1.2 Supported Hash Algorithms
The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC
is safer than normal keyed hashes. Other hash algorithms MAY be
supported by def.
IANA will assign the numbers to identify the algorithm being used as
described in Section C.
B.3.1.3 SPI and Security Parameters Negotiation
SPI's can be negotiated either manually or using an Internet Key
Management protocol. Manual keying MUST be supported. The following
parameters are associated with the tuple <SPI, DCS ID>- lifetime,
Algorithm, Key. Lifetime indicates the duration in seconds for which
the key is valid. In case of manual keying, this duration can be
infinite. Also, in order to better support manual keying, there may
be multiple tuples active at the same time (DCS ID being the same).
Any Internet standard key management protocol MAY be used to
negotiate the SPI and parameters.
B.3.1.4 Message Processing
At the time of adding the authentication extension header, LS looks
up in a table to fetch the SPI and the security parameters based on
the DCS ID. If there are no entries in the table and if there is
support for key management, the LS initiates the key management
protocol to fetch the necessary parameters. The LS then calculates
the hash by zeroing authentication data field before calculating the
MAC on the sending end. The result replaces in the zeroed
authentication data field. If key management is not supported and
authentication is mandatory, the packet is dropped and this
information is logged.
When receiving traffic, an LS fetches the parameters based on the SPI
and its ID. The authentication data field is extracted before zeroing
out to calculate the hash. It computes the hash on the entire payload
and if the hash does not match, then an "abnormal event" has
occurred.
B.3.1.5 Security Considerations
It is important that the keys chosen are strong as the security of
the entire system depends on the keys being chosen properly and the
correct implementation of the algorithms.
SCSP has a peer to peer trust model. It is recommended to use an
Internet standard key management protocol to negotiate the keys
between the neighbors. Transmitting the keys in clear text, if other
methods of negotiation is used, compromises the security completely.
Data integrity covers the entire SCSP payload. This guarantees that
the message was not modified and the source is authenticated as well.
If authentication extension is not used or if the security is
compromised, then SCSP servers are liable to both spoofing attacks,
active attacks and passive attacks.
There is no mechanism to encrypt the messages. It is assumed that a
standard layer 3 confidentiality mechanism will be used to encrypt
and decrypt messages. As integrity is calculated on an SCSP message
and not on each record, there is an implied trust between all the
servers in a domain. It is recommend to use the security extension
between all the servers in a domain and not just a subset servers.
Any SCSP server is susceptible to Denial of Service (DOS) attacks. A
rouge host can inundate its neighboring SCSP server with SCSP
packets. However, if the authentication option is used, SCSP
databases will not become corrupted, as the bogus packets will be
discarded when the authentication check fails.
Due to the pairwise authentication model of SCSP, the information
received from any properly authenticated server is trusted and
propagated throughout the server group. Consequently, if security of
any SCSP server is compromised, the entire database becomes
vulnerable to curruption originating from the compromised server.
B.3.2 SCSP Vendor-Private Extension
Type = 2
Length = variable
The SCSP Vendor-Private Extension is carried in SCSP packets to
convey vendor-private information between an LS and a DCS in the same
SG and is thus of limited use. If a finer granularity (e.g., CSA
record level) is desired then then given client/server protocol
specific SCSP document MUST define such a mechanism. Obviously,
however, such a protocol specific mechanism might look exactly like
this extension. The Vendor Private Extension MAY NOT appear more
than once in an SCSP packet for a given Vendor ID value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID
802 Vendor ID as assigned by the IEEE [7].
Data
The remaining octets after the Vendor ID in the payload are
vendor-dependent data.
If the receiver does not handle this extension, or does not match the
Vendor ID in the extension then the extension may be completely
ignored by the receiver.
C. IANA Considerations
Any and all requests for value assignment from the various number
spaces described in this document require proper documentation.
Possible forms of documentation include, but are not limited to, RFCs
or the product of another cooperative standards body (e.g., the MPOA
and LANE subworking group of the ATM Forum). Other requests may also
be accepted, under the advice of a "designated expert". (Contact the
IANA for the contact information of the current expert.)
References
[1] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM",
Laubach, RFC2225, April 1998.
[2] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC2332,
April 1998.
[3] Moy, J., "OSPF Version 2", STD 54, RFC2328, April 1998.
[4] "P-NNI V1", Dykeman, Goguen, 1996.
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC2022, November 1996.
[6] Keene, "LAN Emulation over ATM Version 2 - LNNI specification",
btd-lane-lnni-02.08
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[8] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC2335,
April 1998.
[9] Luciani, J., "A Distributed ATMARP Service Using SCSP", Work In
Progress.
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing
for Message Authentication", RFC2104, February 1997.
Acknowledgments
This memo is a distillation of issues raised during private
discussions, on the IP-ATM mailing list, and during the Dallas IETF
(12/95). Thanks to all who have contributed but particular thanks to
following people (in no particular order): Barbara Fox of Harris and
Jeffries; Colin Verrilli of IBM; Raj Nair, and Matthew Doar of Ascom
Nexion; Andy Malis of Cascade; Andre Fredette of Bay Networks; James
Watt of Newbridge; and Carl Marcinik of Fore.
Authors' Addresses
James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-03
Billerica, MA 01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Grenville Armitage
Bell Labs Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
Phone: +1 201 829 2635
EMail: gja@lucent.com
Joel M. Halpern
Newbridge Networks Corp.
593 Herndon Parkway
Herndon, VA 22070-5241
Phone: +1-703-708-5954
EMail: jhalpern@Newbridge.COM
Naganand Doraswamy
Bay Networks, Inc.
3 Federal St, BL3-03
Billerice, MA 01821
Phone: +1-978-916-1323
EMail: naganand@baynetworks.com
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.