Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
2. AR request resource to QoS. If the flow is not registered in the AR, AR requests some resource
usage instructions to QoSBroker sending some message with the identification of the flow
(CoA+ DSCP code+ dest. Address);
3. QoS Broker answers. QoS Broker checks its network availability conditions and allows or
rejects that flow;
4. AR applies QoS Broker decision. In a positive answer from QoSBroker AR reconfigure itself,
and stop discarding the MT packets. In a negative answer it continues discarding MT packets
and doesn’t do any reconfiguration.
This process can be illustrated in Figure 98. In (1) the first packet from the MN is represented. This
packet will trigger the request from the QoSB – which should already have the relevant information for
that user (MN). Until the response from the QoSB arrives (3) the packets are discarded. According to the
initial tests´, only the first packet is discarded. After the authorization from the QoSB (which depends on
the administrative settings provided by the AAAC to the QoSB, and the resource management made by
the QoSB) the packets are then transmitted to the network.
Note that this process can be easily extended to support RSVP -aware applications, processing the RSVP
request in function of QoSB commands for that request.
The figure also shows the situation at a CN, in another domain. First, there will exist proper agreements
between both domains. These agreements are reflected at AAAC-level, and typically will convey rules to
be enforced by QoSBrokers at the respective Border Gateways. All this process is not represented in the
Figure. The figure does represent the flow authorization when the packets transverse domains. The first
packet arriving the egress router (AR2) in the foreign domain, will require authorization to be transmitted
to the CN (e.g. because the CN is on a wireless net). AR2 then contacts its local QoSB, which will then
issue the control information for the AR2 (imply for instance the establishment of a bi-directional
connection between AR2 and CN). Note that in most cases QoSB2 will not need to contact any AAAC
for information. The QosB will, in principle, trust the packets that are arriving from its network
interfaces, and proceed based in the DSCP code of the incoming packet – its significance will be assured
by the transformations/policies made at the ingress of the domain.
Notice that this view is optimised for a small number of services defined across operators. For general
widespread service provision, specific requests to the AAAC entities would be required – however, either
service agreements were already in place between those operators (which basically is the situation defined
here), or dynamic service negotiation would be required –situation which is not foreseeable in a near
future.
MN AR QoSB1 AAAC1 CORE AAAC2
QoSB2
AR2
CN
Trunking Agreement
& SLA Mapping
1
2
3
4
8
7
5
6
Figure 98: “Flow” authorization
AAAC.f ßà SP’s AAAC, AR --- DIAMETER
AAAC.f ßà QoS Broker --- COPS
QoSBroker ßà AR --- COPS, (SNMP, CLI)
No. Message Content / Parameters Remarks
1 1 st packet of a CoA, Destination, DSCP This packet will be discarded by the AR, but
D0103v1.doc 152 / 168