Introduction

In this document, we discuss the flows of the BB inter-domain protocol and the actions taken by the BBs when these flows are received. In all the scenarios that follow, we do not take the error or rejection cases into account. This document is meant to provide a basis for the explanation and discussion of the details of the protocol.

Scenario 1: Microflow reservation

In this scenario, there is an individual reservation that originates at a host in the origin domain. There is no core tunnel used, and the reservation request has a destination in another domain.

The client node sends a request via an intra-domain BB client-server protocol. The BB server should consult several databases: First, the local policy database which causes it to apply local domain policy to the request. If the request survives that test, the BB goes on to consult the resource and topology database for the domain in addition to the routing database. From the routing database, the BB determines:

The path through the local domain
The next-hop network required to send the traffic covered by the request on to the destination

Note that a complex BB could at this point cause an MPLS LSP to be set up, at least through its own domain.

From the resource and topology database, the BB checks whether there is sufficient capacity in its own transport network to provide the requested resources.

From the knowledge of the next-hop domain the BB determines the egress router from its own domain, possibly load balancing flows (but not individual packets) across a set of egress routers. The issue of load balancing is one that each implementer can decide to do as experimental work. At each of these potential egress routers, there is an SLS which the BB is able to access (perhaps it has a database of them, or perhaps they can be accessed from the policy server, e.g.) and which the BB uses to determine whether the requested resources "fit" the SLS. The exact procedure for determining whether the resources fit is a research topic. The protocols used to access teh database are locl to teh domain nd are not specificed by the inter-domain protocol.

If the BB finds sufficient resources within its own domain and on the inter domain link governed by a particular SLS, it marks these resources as reserved within its data base. At this point, we assume that the egress router at least is pinned (if not the entire set of routers used to reach the egress from the client). Once these determinations are made, the BB determines the IP address of the peer BB in the next hop domain and sends an RAR on to its peer BB.

Note that the BB could configure the egress router interface at this point with the appropriate policing/marking/shaping mechanisms for this flow. The ingress interface MUST however block any communication destined for the desired reservation before an acknowledging RAA is sent to the originating host.

The RAR is encoded as follows (note: in general, wherever default settings (or operation) may be applied, the relevant default settings (or operations) are used):

First a SIBBS PDU is created

The version is SIBBS version 1

Sender ID is set to the domain name of the sending BB's domain

The Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.

The SIBBS PDU contains a RAR message, consisting of mandatory parameters only (i.e. no optional parameters included).

The first parameter of the RAR message is the RAR ID:

Type is normally default: IPv4

IPv4 address of the BB creating this message

The sequence number is created from stable storage by adding 1 to the value there

Since this is the first RAR associated with the reservation, the extension number is 0 [Some systems apply random settings as starting values - which is meant to increase security again (don't always start with 0).However, in the interests of keeping the protocol simple, we will start with 0 for the first release.]

The Source Address prefix is the originating host (It could also be the longest prefix of its IPv4 address that the domain needs to make available for the application of policy).

The destination address prefix in this case is the full IPv4 address of the destination host.

The next parameter is the Ingress Router ID:

The ingress router ID is derived from the pinned egress router for the originating domain. In this case, it is the IP address of the ingress interface of the domain to which the RAR is being forwarded. This gives the receiving BB the exact link and router that will be used as the ingress to its domain.

The next parameter of the RAR is the SPO:

The SPO service type is set to default: 0x0001 [Thought if the 2exp0 Bit is set it means "one"] (QBone Premium Service)

The P-Bit is set to b'1' indicating a globally defined service.

The service-specific parameters of the SPO are set as follows:

PHB code is set to default: the EF DSCP code (RFC 2598)

The DSCP is set to default: EF (b'101110')

The Peak rate is set to the number of octets per second desired by the reservation

We don't define any experimental values for release 1

The start time vector is omitted (operational default).

The end time vector is omitted. (operational default - Implies that the reservation will be explicitly taken down by the originating BB).

The RAR Flags TLV is omitted (operational default).

The BB signs the SIBBS PDU containing the RAR message and inserts the signature. Then the originating BB sends the newly created RAR to the selected downstream BB. At this time, the RAA_pending_Timer is activated.

The RAR is received by the peer BB. This BB processes the RAR in a way that is similar to the way the origin BB processed the request from the client.

The BB checks the syntax of the RAR message.
The BB decodes the signature of the SIBBS PDU and evaluates it against the credentials it stored from the sending BB and the settings of the received RAR message.
The BB checks whether the local database contains an entry referring to the received RAR ID. If this is not the case, the RAR ID , the Ingress Router ID, the SPO, and the Sender ID identifying the sending BB are saved.
The BB checks the consistency of the parameters passed in the RAR message.
The BB applies local domain policy to the information in the RAR to decide whether to accept.
The BB checks the routing database to determine the next-hop domain on the way to the destination and determines the egress router in its domain. This process is essentially the same as is used by the origin BB, including the same considerations.
The BB checks the SLS associated with the egress router to see whether the RAR will "fit" under the SLS.
The BB checks the topology and resource databases to ensure that enough capacity exists in the transport network to provide the requested service.
If the BB finds sufficient resources within its own domain and on the downstream inter domain link governed by a particular SLS, it marks these resources as reserved within the topology and resource data base.

Note: The BB may pin the route from the ingress router to the egress router in order to ensure that the QoS of the RAR is met. The intermediate BB changes the SIBBS PDU containing the RAR message as follows:

Sender ID is set to the domain name of the sending BB's domain
Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.
The RAR messages parameter Ingress Router ID is modified:

The Ingress Router Address is derived from the pinned egress router for the originating domain. In this case, it is the IP address of the ingress interface of the domain to which the RAR is being forwarded.

The same processing is performed by all the intermediate BB nodes.

At the destination domain's BB, all the checks listed above are made. If the RAR contains a complete destination address, the path to the destination host, instead of the next-hop domain, is checked for reachability and resource availability. The destination host is contacted via an intra-domain protocol, to ensure that the reserved flow(s) can be accepted. The destination domain BB may at this point configure the routers along the internal path to support the reservation requested. The BB may also at this point configure any required policers/shapers/markers on the ingress interface referenced in the RAR and further any configuration of the outgoing (towards the destination host) interfaces that may be necessary is done at this time.

If the RAR is accepted by the destination BB after all the policy and resource checks are made, then the destination domain's BB creates an RAA for the RAR.
The RAA is encoded as follows (note that in general, wherever default settings (or operation) may be applied, the relevant default settings (or operations) are used):

First A SIBBS PDU is created

the version is SIBBS version 1
Sender ID is set to the domain name of the sending BB's domain (which in this case is the destination domains BB)
The Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.
The SIBBS PDU contains a RAA message, consisting of mandatory parameters only (i.e. no optional parameters included).
The first parameter of the RAA message is the RAR ID, which is mostly copied from the received RAR message:

Type is copied from the RAR ID
"Originating BB-IP Address" is copied from the RAR ID
The sequence number is copied from the RAR ID
The received Extension is incremented by one
The Source Address Prefix is copied from the RAR ID
The Destination Address Prefix is copied from the RAR ID

The Ingress Router ID is copied from the RAR message
The SPO is copied from the RAR message

The BB signs the SIBBS PDU containing the RAR message and inserts the signature. Then it sends it to the preceding BB it received the corresponding RAR message from. At that time, the destination BB starts the Refresh_pending_Timer. The destination BB now must configure the routers of its domain to provide the agreed resources.

The RAA is received by the preceding peer BB. This BB processes the RAA as follows:

The BB checks the syntax of the RAA message.
The BB decodes the signature of the SIBBS PDU and evaluates it against the credentials it stored from the sending BB and the settings of the received RAA message.
The BB checks whether the local database contains an entry referring to the RAR ID settings as received by the RAA message. This is true if

The Type must match the value saved in the local data base.
The Originating BB-IP Address must match the value saved in the local data base.
The Sequence Number must match the value saved in the local data base.
The Extension must match the value saved in the local database incremented by one.
The Source Address Prefix must match the value saved in the local data base.
The Destination Address Prefix must match the value saved in the local data base.

The BB checks the consistency of the parameters passed in the RAA message. It however does not compare the Ingress Router ID or the SPO against any values saved in its local data base.
The sets the state of the reservation to "Reservation active" in its database entry related to the RAR ID and resets the Refresh_pending_Timer.

The intermediate BB changes the SIBBS PDU containing the RAA message as follows:

Sender ID is set to the domain name of the sending BB's domain
Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.
The RAA message parameter Ingress Router ID is modified:

The Ingress Router Address is replaced with the value saved in the local data base.

The RAA is then forwarded to the preceding BB on the TCP session that it has with the peer BB. At that time, the intermediate BB starts the Refresh_pending_Timer again. At the latest, the intermediate BB now must configure the involved routers of its domain to provide the agreed resources.

The originating BB performs the same checks and informs the local user of the successful reservation set up. It stops the RAA_pending_Timer and starts the Refresh_Create_Timer. Note that the duration of the Refresh_Create_Timer MUST be smaller than that of the Refresh_pending_Timer.

Scenario 2: Microflow reservation refresh

The originating BB is in charge of continuously refreshing the reservations it initiated. For this purpose, Refresh messages are created at regular intervals. Creation of a new refresh message is triggered by the expiration of the Refresh_Create_Timer referring to a particular reservation (identified by the RAR ID). In this case the originating BB creates a new SIBBS PDU:

The version is SIBBS version 1

Sender ID is set to the domain name of the sending BB's domain

The Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.

The SIBBS PDU contains a Refresh message.

The only parameter of the Refresh message is the RAR ID. It is copied unchanged from the local reservation database with one exception:

The extension number is copied from the reservation data base and incremented by one.

The BB signs the SIBBS PDU containing the Refresh message and inserts the signature. Then the originating BB sends the Refresh to the downstream BB whose address is saved under the RAR IDs entry in the local data base.. At this time, the originating BB activates the Refresh_Create_Timer again. The BB may reset all local Policy and Resource data base entries and the Router configurations to a state without the reservation just released.

The Refresh message is received by the peer BB. This BB processes the Refresh message as follows:

The BB checks the syntax of the Refresh message.
The BB decodes the signature of the SIBBS PDU and evaluates it against the credentials it stored from the sending BB and the settings of the received Refresh message.
The BB checks whether the local database contains an entry referring to the received RAR ID.
The BB checks whether the Extension of RAR ID equals the value of the Extension saved in its local data base incremented by one.
The BB stops the Refresh_pending_Timer.

The intermediate BB changes the SIBBS PDU containing the Refresh message as follows:

Sender ID is set to the domain name of the sending BB's domain
Sender Signature is created based on the message contents and on the security model created by Andy Adamson and Volker Sander.

The Refresh message is then forwarded to the following domain on the TCP session that it has with the peer BB whose address was found under the RAR IDs entry in the local BB data base. At that time, the intermediate BB starts the Refresh_pending_Timer.

The same processing is performed by all the intermediate BB nodes and also by the destination BB. The latter however doesn't create or send a new SIBBS PDU and hence simply restarts the Refresh_pending_Timer instead of just stopping it once it recognized the Refresh message as valid.

Scenario 3: Microflow reservation release

The origination (or destination) BB may by customer signaling or by other means reach the conclusion that an active reservation no longer is required. It will create a correctly coded RAR message containing an SPO with a zero (0) QPS-Peak-Rate reservation. A new SIBBS PDU is created

The version is SIBBS version 1

Sender ID is set to the domain name of the sending BB's domain

The Sender Signature is created based on the message contents and on the security model created by Andy Adamson and Volker Sander.

The SIBBS PDU contains a RAR message, consisting of mandatory parameters only (i.e. no optional parameters included).

The first parameter of the RAR message is the RAR ID. It is copied unchanged from the local reservation database with one exception:

The extension number is copied from the reservation data base and incremented by one.

The Ingress Router ID is copied from the reservation database.

The SPO is copied from the reservation database with one exception:

The QPS Peak Rate is set to zero (0).

The start time vector is omitted (operational default).

The end time vector is omitted (operational default).

The RAR Flags TLV is omitted (operational default).

The BB signs the SIBBS PDU containing the RAR (0) message and inserts the signature. Then the originating BB sends the RAR (0) to the downstream BB whose address is saved under the RAR IDs entry in the local data base. At this time, the BB activates the RAA_pending_Timer. The BB may reset all local Policy and Resource data base entries and the Router configurations to a state excluding the reservation just released, or this may be done after the RAA is received.

The RAR (0) is received by the peer BB. This BB processes the RAR (0) in a way that is similar to the way the origin BB did.

The BB checks the syntax of the RAR message.
The BB decodes the signature of the SIBBS PDU and evaluates it against the credentials it stored from the sending BB and the settings of the received RAR message.
The BB checks whether the local database contains an entry referring to the received RAR ID.
The BB checks whether the Extension of RAR ID equals the value of the Extension saved in its local data base incremented by one.
The BB checks the consistency of the parameters passed in the RAR message.
The BB identifies the RAR as a request to release this reservation by reading the demanded QPS-Peak-Rate of zero(0).
The BB checks the local database to find identify the correct downstream BB to forward the RAR(0) to.

The intermediate BB changes the SIBBS PDU containing the RAR message as follows:

Sender ID is set to the domain name of the sending BB's domain
Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.
The RAR messages parameter Ingress Router ID is modified:

The Ingress Router Address is derived from the pinned egress router for the originating domain. In this case, it is the IP address of the ingress interface of the domain to which the RAR is being forwarded.

The RAR is then forwarded to the following domain on the TCP session that it has with the peer BB. At that time, the intermediate BB saves the state "RAA pending" in its database entry related to the RAR ID and starts the Refresh_pending_Timer. The BB may reset all local Policy and Resource data base entries and the Router configurations to a state excluding the reservation just released.

The same processing is performed by all the intermediate BB nodes.

At the destination domain's BB, all the checks listed above are made. If the RAR(0) contains a complete destination address, the destination host is contacted via an intra-domain protocol, to ensure that the reserved resources are released there too. The destination domain BB may at this point configure the routers along the internal path to remove all router settings and Policy and Resources data base entries related to the released reservation. The BB may also at this point reset any required policers/shapers/markers on the ingress interface referenced in the RAR(0) and further any configuration of the outgoing (towards the destination host) interfaces that may be necessary to a state excluding the resources consumed by the released reservation.
Then the destination domain's BB creates an RAA corresponding to the RAR (0). The RAA is encoded as follows (note that in general, wherever default settings (or operation) may be applied, the relevant default settings (or operations) are used):

I stopped here. I think only one of the following options should be allowed (I'd prefer the negative ACK). I a zero reservation causes a Problem, why not sending an all 1 (1111111...1) instead?

It doesn't matter whether the local BB reacts by a RAA granting 0 resources or whether it is denying the requested resources: A negative RAA results in a release of resources anyway. A RAA confirming a 0 reservation MUST result in a release of resources too. A 0 reservation is always positively acknowledged. We could also consider the origin just sending a CANCEL with a reason code = reservation teardown.

Scenario 4: Cancelling a reservation

The owner of a reservation may release a reservation by sending an RAR with a 0 rate resorce reservation. All other Bandwidth Brokers can release a reservation only by a Cancel message. A release of a reservation may result from several situations.

Scenario 4.1: Cancel due to refresh time out

After the Refresh_pending_Timer timed out for the first time in an intermediate BB, the intermediate BB MUST NOT release the reservation. It MUST instead start the Refresh_pending_Timer again an set a Refresh_Timeout counter to 1. After the Refresh_pending_Timer timed out n times (where n is small integer, typically n=3), the intermediate BB changes state to Resrevation_timeout_pending and starts the Refresh_pending_Timer for the last time. If it again times out, the intermediate BB MUST create a Cancel message. A new SIBBS PDU is created

The version is SIBBS version 1

Sender ID is set to the domain name of the sending BB's domain

The Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.

The SIBBS PDU contains a Cancel message.

The only parameter of the Cancel message is the Cancel Range TLV. It contains the following information:

Type is set to default: IPv4 address of the canceling BB is provided.

The IPv4 Address of the local BB (the BB which decided to cancel the reservation).

The NRAR ID is set to 1.

The canceled RAR ID is the RAR ID of the reservation which timed out as copied from the local data base with one exception:

The extension number is copied from the reservation data base and incremented by one.

The BB canceling the reservation inserts its public key as Originator Signature.

The BB signs the SIBBS PDU containing the Cancel message and inserts the signature. Then the originating BB sends the Cancel message to the upstream and downstream BB whose addresses are saved under the RAR IDs entry in the local data base. At this time, the sending BB resets all local Policy and Resource data base entries and the Router configurations to a state excluding the reservation just released. It further removes all state of the reservation from the local data base.

The Cancel message is received by the peer BB. This BB processes the Cancel message as follows:

The BB checks the syntax of the Cancel message.
The BB decodes the signature of the SIBBS PDU and evaluates it against the credentials it stored from the sending BB and the settings of the received Refresh message.
The BB checks whether the local database contains an entry referring to the received RAR ID.
The BB checks whether the Extension of RAR ID equals the value of the Extension saved in its local data base incremented by one.
The BB stops the Refresh_pending_Timer.

The intermediate BB changes the SIBBS PDU containing the Cancel message as follows:

Sender ID is set to the domain name of the sending BB's domain
Sender Signature is created based on the message contents and on the security model to be created by Andy Adamson and Volker Sander.

The Cancel message is then forwarded to the preceeding or following domain (depending on the cancel message being forwarded up- or downstrem) on the TCP session that it has with the peer BB whose address was found under the RAR IDs entry in the local BB data base. At that time, the sending BB resets all local Policy and Resource data base entries and the Router configurations to a state excluding the reservation just released. It further removes all state of the reservation from the local data base.

The same processing is performed by all the intermediate BB nodes and also by the origin and destination BBs. The latter two however don't create or send a new SIBBS PDU and hence just reset all local Policy and Resource data base entries and the Router configurations to a state excluding the reservation just released. They further remove all state of the reservation from the local data base. (The origin BB stops and removes the Refresh_Create_Timer instead of the Refresh_pending_Timer.)

The management systems of the origin and destination BB should create an alarm in the case of a release of a reseravtion by a Cancel message.

P.F. Chimento and Rüdiger Geib