Hi Andy,

Here are some pointers, i could think of for the challenges:

1. A component based architecture for network management can simplify
lot of complex details, including many details of application
behavior, because the application developers no longer need to develop
applications conforming to some operating system API or network
mechanism API, and those complex details/configurations can be
automatically added by the middleware in a declarative as well as
configurable manner. 

2. BB uses Access Control Lists available on COTS network elements to
classify traffic into flows that can be policed, so that QoS can be
met. But inorder to classify and police the flow, the source address,
destination address, source port, dest port and protocols need to be
known in advance. 

In component middleware, the applications are written with the hope
that the middleware will take care of the protocol to be used, and the
D&C tools will take care of deploying the applications. This means
that the applications do not know either of the 5 things required. 

In fact until deployment time, the applications do not know any of the
5 things required, and at run-time they can also be dynamically
migrated and reconfigured, which means that the 5 things can change at
any time. 

The common thing that can be used to police traffic are the DiffServ
Codepoints,  which can be used to mark the packets whenever the
components make a communication. Then each class of traffic can be
policed using mechanisms such as Committed Access Rate, and all the
networking elements can be configured to take such actions, when they
see packets with particular DSCP markings. 

So its upto the middleware to configure the applications with the
appropriate DSCP codepoints, when the applications make calls amongst
themselves. This way, the applications can be moved anywhere in the
network, but as long as they conform to the network bandwidth
utilization they agree to, they can send messages from any network,
and the network devices could be configured to act according to the
DSCP codepoints received in the packets. 

3. Since the applications are going to communicate using the DSCP
codepoints, the routers need to be configured with appropriate actions
when the applications send messages with DSCP codepoints marked. 

Some of the information required by the routers are the flow rate,
what to do if the flow exceeds the allocated rate, what is the
required rate, when the applications make calls. 

All of these information is required for the routers to be configured,
and for the bandwidth broker to give the dscp codepoints to be used by
the applications. And all of these things are needed during the
deployment time, as the network elements and applications need to be
configured only once and it is not feasible to configure the network
elements and the applications at run-time, espicially for mission
critical DRE systems, who cannot waste time at run-time on handling
configuration issues. There may be few time slots available, for
reconfiguration, but still that time may not be as much as the time
available at deployment time. 

Since D&C tools are commonly used to assist in deploying and
configuring the applications, it makes lot of sense to extend such
tools to assist in configuring the networking elements as well as the
applications for providing QoS. (Also, add few sentences on how
modeling tools can handle the gory details on maintaining flow
information, etc) 

4. End-to-end integration of all of these activities, and that is done
by using XML, and how we can actually minimize mistakes in writing
those XML, or parsing those XML and how the XML schema can be easily
used to actually encode lot of details. 

Thanks,
    Jai