![12 NEMA Proceedings
The construct of the middleware API does not depend upon the model,
however, the value of arguments passed are model-dependent. For example,
the URI arguments in the APIs identify the target object instance to create,
read, update, delete or execute. It may also identify a collection of object
instances as in the case of a Collection URI (COL-URI) for manipulation of a
collection of objects and data. The DataIn and DataOut arguments
signify the variant types of data that may be passed between the client and the
identified target object(s). The middleware API is illustrated below in pseudo
code.
errorcode create(URI);
errorcode readConfigData(DataOut, URI);
errorcode readOperationalData(DataOut, URI);
errorcode updateConfigData(DataIn, URI);
errorcode delete(URI);
errorcode execute(DataOut, DataIn, URI);
When the middleware receives a call across this interface, it resolves the
URI to the object instance and performs the associated Instrumentation API
call for the entity.
readOperationalData(long&
lRate,”/services;servicename=
/IFFlowMon/probes;id=/Q/flowRate”
);
The middleware resolves this information to a call to the instrumentation
API shown here in trivial pseudo code:
Q=get(”/services;servicename=/IFFlowMon/probes;id=
/Q”);
lRate=Q->readIntefaceFlowProb_flowRate(ErrorOut);
While most of the fine details of the middleware and instrumentation API
interactions have been excluded, the example illustrates the design choices
and resulting concepts of middleware and instrumentation API construction
from the instrumentation model.
5 Related Work
There is a great deal of work that has been done in the area of Model-Driven
Engineering (MDE) over the past three decades and was crystallized with the
formation of the Object Management Group (OMG) [10] in 2001. The OMG
was formed to establish modeling and model-based standards. Since that](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-28-320.jpg)
![Transitioning Management Instrumentation 13
time, the promises of MDE have been elucidated for the development of new
applications, providing modeling tools, development tools, domain specific
languages, and the like. A virtual plethora of standards and applications have
been created to support the development of new model-driven applications,
however little has been done to address the cost effectiveness of leveraging
existing systems in a model-driven environment. Douglas Schmidt [4] in his
February 2006 Model-Driven Engineering overview states “When developers
apply MDE tools to model large-scale systems containing thousands of
elements, they must be able to examine various design alternatives quickly
and evaluate the many diverse configuration possibilities available to them.”
He refers to the Integrated Modeling Approach of Lockheed Martin Advanced
Technology Laboratories as an example of legacy integration with less than
ideal results: “Reverse engineering is used to build models… from existing
source code. Many previous attempts to reverse-engineer models from source
code have failed due to a lack in constraining aspects of interest.” A similar
experience described in this paper.
In his article “The Pragmatics of Model-Driven Development”, Bran
Selic[6] discusses legacy integration mostly in terms of development tooling
only tangentially touching upon the issue of leveraging application source
code in the modeled environment. In this case, the recommendation was to
take advantage of legacy code libraries and other legacy software where
domain-specific knowledge often resides. While certainly true, this view
overlooks the problems of impedance mismatch between the two designs and
often-prohibitive implementation cost of custom glue code.
At the UML Conference of 2003, Jean Bezivin [2] presented “MDA: From
Hype to Hope, to Reality” where it was stated: “The extraction of MDE-
models from legacy systems is more difficult but looks as one of the great
challenges of the future. There is much more to legacy extraction than just
conversion from old programming languages”. Indeed, it is the variability of
legacy systems, platforms and ultimately the model impedance mismatch that
is at the heart of these challenges.
Unfortunately, most work in the Model-Driven Engineering area focuses on
the rapidly accelerating model-driven technologies and patently avoids
dealing with the big white elephant in the middle of the room – how to
leverage the existing application features and functionality in an efficient and
cost-effective manner.](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-29-320.jpg)
![Low Power, Programmable Networking Platform 21
cases are switching, routing devices, NAT devices, firewalls, deep packet
inspectors, and traffic loopback devices.
The system has been designed and developed by applying a close
hardware-software co-design methodology. This primarily defined the
distribution of tasks among the various types of processors. Beside, this
flexibility allowed the clarification of basic processing modules and
algorithms, which enabled to create a programmable networking platform.
For design space exploration and to validate the design, a SystemC [1]
based modeling environment is used. The results of the SystemC modeling
can be used to construct the final hardware models and the corresponding
software. The SystemC hardware components are also available in generic
hardware description language (Verilog/VHDL) making the synthesis of the
hardware possible. The developers will also be able to generate the top-level
hardware model through the GUI. The modules required for the generic
networking applications have been selected by identifying the most important
use cases.
After the literature survey in the next chapter, we briefly describe the
hardware, the firmware, and the development environment to be used for
various networking applications hosted by the platform. Afterwards we
highlight the usability of the environment through two use-cases: a network
monitoring DPI scenario and a routing/switching scenario.
2 Related Work
In the literature, we have found similar work dealing with packet
processing on FPGA-based systems.
Besides the industry leading Endace DAG packet capture products [3], the
NetFPGA [4] platforms are largely in use in academic research to test for
ideas and implement them on flexible hardware. The TenGig NetFPGA card
is currently under development, and it will be capable of 10G traffic handling.
It will provide 4 XFP ports RLDRAM II, QDRII, SRAM, PCIe 8x interface
and extension connector, powered by a large Xilinx Virtex-5 FPGA,
XC5VTX240T which is quite expensive. A similar platform is developed
within the Cesnet Liberouter project [5], which already provides a 10G
extension card to their extensible Combo system, making it capable of 10G
packet processing. We would also mention an interesting application of
FPGA-based design platforms for Gigabit Ethernet Applications. FPGA-based
implementations offer the possibility of changing the functionality of the
platform to perform different tasks and high packet-processing rate
capabilities. In particular, the authors of [6] proposed a versatile FPGA-based
hardware platform for Gigabit Ethernet applications. By introducing
controlled degradation to the network traffic, the authors provided an in-depth](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-37-320.jpg)
![22 NEMA Proceedings
study on real-application behavior under a wide range of specific network
conditions, such as file transfer, Internet telephony (VoIP) and video
streaming. Other approaches include hardware accelerated routing, e.g. the
work of D. Antos et al. [7] on the design of lookup machine of a hardware
router for IPv6 and IPv4 packet routing with operations are performed by
FPGA. In this framework, part of the packet switching functionality is moved
into the hardware accelerator, step by step. This allows keeping the complete
functionality all the time, only increasing the overall speed of the system
during the whole development process. D. Teuchert et al. [8] also dealt with
FPGA based IPv6 lookup using a pipelined, tree-bitmap algorithm based
method.
The NetFPGA project also provides a development environment for the
programmable hardware platform. Their approach [10] is to provide reference
architectures (interface card, switch, router, etc.) as starting points for new
development. To avoid the necessity of hardware level programming and
provide a high level interface, a framework is presented in [11] to incorporate
hardware G modules into NetFPGA based system designs.
Although there are several similar approaches [9], none of them fulfills the
requirements of the C-Board. The existing hardware is not fast or not scalable
enough, while also the development environment lacks the flexibility and the
required simplicity.
3 The SCALOPES C-board
The ARTEMIS SCALOPES project aims at developing and utilizing novel
methods in low power, high performance embedded platforms. Our
SCALOPES C-board is the prototype platform for the communication
infrastructure-related applications inside the project. The main purpose of the
C-board is to provide a basis for high-speed data processing and manipulation.
It could either host or serve monitoring, switching, routing, filtering and other
applications that require real-time processing of 10 Gigabit Ethernet traffic. In
the following sections the motivations, requirements and the state of the art is
surveyed, followed by the brief description of the architecture.
3.1 Motivation and Requirements
Real time analysis and manipulation of 10 Gigabit Ethernet traffic requires
scalable, high performance equipment. Clear and easy-to-use management
and programming interfaces further ease the task of the user of such
equipment. There are some programmable networking platforms already](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-38-320.jpg)
![Low Power, Programmable Networking Platform 23
available in the field, nevertheless, upto this date we have not found another
platform that
- is both programmable in hardware and software,
- can manipulate the traffic by utilizing PCIe-connected controllers,
- has capabilities to directly forward 10Gbps Ethernet traffic to/from 1Gbps
Ethernet or SONET,
- is designed for measurable low power consumption, and
- has lowered risks for extra developments since composability,
predictability and dependability [2] issues are tackled.
The SCALOPES C-board was designed and developed with the ultimate
intention of putting the above requirements into practice.
3.2 Internal Structure
The practical capabilities of any networking equipment are limited by its
internal elements, their programmability, and its interfaces’ types, modes, and
speed. During the development of the SCALOPES C-board, the requirements
were set high: it is a highly scalable device with a well-defined programming
toolchain, capable of manipulating traffic arriving from SONET, ATM,
Gigabit and 10 Gigabit Ethernet, routing/switching the traffic between these
interfaces and further controlling or processing it through PCIe x4 extension
modules. The simplified architecture of the board is depicted by Fig. 1.
The main components of the device are the following:
- XFPs (10 Gigabit Small Form Factor Pluggable Modules) connecting to
XAUIs (10 Gigabit Attachment Unit Interface) for 10 Gbps traffic
reception,
- SFPs (Small Form/factor Pluggables) to handle various Gigabit Ethernet
ports, for output to devices,
- four FPGAs (Field-Programmable Gate Arrays) connected in a matrix,
used for packet capture and manipulation, including interface handling,
traffic flow handling firmware blocks, basic statistical modules,
- memory for packet buffering and flow tables,
- extra processor for on-board processing and management software,
- redundant power supply.](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-39-320.jpg)
![28 NEMA Proceedings
The development environment consists of a modeling environment, where
the application is modeled in SystemC, and a hardware/software co-design
methodology, utilizing commercially available programming tools as well.
The development environment gives access for different levels of
complexity, from basic GUI-based modifications to full simulation/modeling
and co-design.
4.1 GUI based development
Starting from a provided generic application architecture, custom firmware
can be easily generated using available “filters”. There are several generic
modules available for packet manipulations that can be inserted at the packet
input/output processing stages of the architecture. These modules may also
provide a software interface, for setting filter rules, reading statistics etc. For
example, a simple firewall can be created by adding input and output filter
blocks to the generic packet forwarding application. Adding NAT
functionality means inserting a NAT module at the egress interface.
Fig. 3 shows the structure of the development environment. The whole
development process can be done using the provided GUI. The GUI is written
in Java, integrates the tools into a development environment and provides
editing functions. The available modules are described in IP-XACT [12]
XML format, and they can be selected from the toolbox and with simple drag-
and-drop operations they can be inserted in the architecture. Composability is
ensured by using the IP-XACT specification format, and is automatically
checked while connecting the interfaces. Both the SystemC and VHDL
sources for the different modules are also provided, along with their IP-XACT
description. The new design can be tested by the SystemC simulation
framework, which provides traffic generators for performance testing and
predictability analysis. The top-level HDL file is generated automatically
based on the connections made on the GUI, and the final firmware can be
synthesized using the Xilinx ISE. As the new application is a modified
version of the generic application with filter components added, its
performance should not change, only an insignificant the latency is introduced
by the filters.
Besides the composability checking, a dependability and predictability
analysis is also possible. The framework will be extended to generate a
Continuous Time Markov Chain (CMTC) based dependability model of the
system stored in a view in the IP-XACT description, which can be used in
open-source simulators like the PRISM model checker [13]. A queuing model
of the hardware can also be created, which makes possible the analysis and
queue dimensioning for different traffic mix scenarios.](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-44-320.jpg)
![Low Power, Programmable Networking Platform 29
4.2 Custom module development
The development of the new applications is also assisted by a number of
available hardware component models that can be used for generic
networking application development. The already available components
define a generic packet processing/forwarding architecture with extensible
filtering and processing properties, and a generic deep packet inspection
architecture. All components come with SystemC and VHDL source code and
IP-XACT description. The extensible, modular architectures are designed to
allow easy integration of application-specific header operations at the ingress
and egress. A method for buffering the packet payload is also provided. Most
of the applications can be covered with the available modules. The
architecture also features a hierarchical power management concept for low
power operation [14].
However, if a custom module is needed for a hardware-level operation
which is not yet available, new modules can be created and added to the
model database by adding the source files to the SystemC and VHDL
directories and creating the IP-XACT XML descriptor. The key issues are the
interfaces of the new component, and the timing requirements. For the most
common operations like input/output processing and flow handling well
defined interfaces are provided with low timing requirements. However, for
line-speed processing all modules must handle back-to-back packet arrivals at
interface speeds. For even easier development generic filter prototypes are
provided with full source code. First, the SystemC model should be created,
for composability and predictability checking. Based on the SystemC model
the HDL model can be created too, and added to the HDL model database.
4.3 Hardware accelerator development
The protocol processing task usually starts with basic input/output operations
like packet reception and queuing. These operations require hardware
processing, for fastest execution. After several stages of header processing, it
may not be suitable for hardware processing because of increased complexity;
software processing is more flexible and desirable. The conventional
networking protocols had simple structure, binary headers and fixed fields.
As we climb the levels of the OSI model, the protocols become more and
more complicated, with variable header lengths and fields. One of the most
difficult protocols to decode are the textual protocols like HTTP and SIP,
where very few things are fixed, fields can be mixed, string identifiers are
used and all fields have variable length. Such protocols require software
processing, involving parsing. There are several methods to enhance the
processing in hardware with accelerator interfaces. Different protocols require](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-45-320.jpg)
![Low Power, Programmable Networking Platform 33
The C-Board with the DPI firmware architecture is capable of monitoring
full speed the 10Gbps traffic in both directions, and it can forward it to the
SFP interfaces without packet loss.
Finally, in a realistic use-case a part of the traffic can be streamed to the
SFPs for packet level analysis. Up to 8 Gbps traffic can be streamed to the
receiving monitor PCs dependably [13].
5.2 Generic Switch/Router architecture
The SCALOPES C-Board can also be used as a generic Switching/Routing
architecture with hardware level packet forwarding. The architecture supports
two 10 GbE ports, 16 GbE ports with an arbitrary combination of SFPs.
Fig. 6. Generic Packet forwarding architecture
The used packet processing pipeline is similar to the model recommended
by Xilinx [15] and the model used by the Liberouter project [5]. The packets
are filtered first, then all traffic is written in the DDRAM for buffering. Since
the memory access can be the bottleneck in our packet processing pipeline,
we tried to avoid copying the packet. We have decided to use the shared-
memory packet forwarding model, this way avoiding unnecessary copying of
data. The model has a further advantage: even multicasting/broadcasting can
be done without actually copying the data.
The generic packet forwarding architecture is shown by Fig. 6. The arriving
packets are buffered, while their header information is however forwarded to
the lookup module. The lookup module is responsible to decide on which
interface the packet should leave. For flooding, broadcast and multicast
multiple interfaces may be selected. For different application types, different
routing/switching modules can be designed, which may operate at different
layers of the OSI model, like L2 switching, IPv4 or IPv6 routing, MPLS
packet switching etc. Based on the decision at the lookup module, a short](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-49-320.jpg)
![34 NEMA Proceedings
internal header information is written in the egress interface queues (multiple
queues in case of broadcast/multicast packets). The output filter block is
responsible for scheduling and queuing, and retrieval of packet data from the
DDRAM and transmitting on the egress interface.
The performance of this architecture is only limited by 2 main factors:
lookup speed and DDRAM access. The lookup speed depends on the L2 or L3
forwarding table size and lookup algorithm, while DDRAM access may
introduce delays in case of small packet sizes.
The generic packet forwarding architecture can be extended with a COM
express based PC board, providing considerable processing power. This
extension opens up further application possibilities for the board. Such a
possible application is a Session Border Controller. Session Border
Controllers (SBCs) have evolved to address the wide range of issues that arise
when voice and multimedia services are overlaid on IP infrastructure. These
include a wide range of operations from packet level monitoring tasks through
flow level manipulation tasks to high level signaling processing tasks, all at
high speeds. These put high demand on both hardware and software. With our
C-board extended with a PC board a high performance SBC can be designed.
The key idea in this use case is the close interworking between the
software processing on the PC board and hardware processing on the FPGA
board. The low level processing handles the high-speed traffic and passes only
the network signaling traffic to the processor. The routing protocols and
forwarding control can be done just like in the previous case. An open
protocol like OpenFlow [16] can be used to control the hardware flow
processing.
6 Summary
The SCALOPES C-board is a versatile programmable platform capable of
handling 10Gbps Ethernet traffic. It provides a base platform for various
packet processing applications such as switching, routing filtering,
monitoring, etc. Its modular structure allows its extension with processing
cards to increase its applications with high-speed software processing as well.
The C-board is accompanied by a development environment to unlock its
full potential. The environment supports the development process from
design-space exploration and modeling in SystemC to modular design. It is
based on predefined hardware modules, from which the basic applications
(packet forwarding, DPI) can be constructed. The development environment
will also feature a graphical user interface, providing easy development for
customization. The scalability and low power requirements have been taken
into consideration for both hardware and software design. We have
demonstrated some major application fields for the hardware on use cases.](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-50-320.jpg)
![the Imperial letter, rode out of the gate of Torcy and ascended the
hill whence the King had witnessed the battle.
King William and his Warriors.
An eminence, selected by the Staff because it commanded an
extensive view, rises a little south of Frenois—the site has been
marked on the map with a small pyramid—and upon this, about
seven o’clock, just as the fog was lifting, King William took his stand.
When the mists vanished, the sun poured his dazzling splendour
over the landscape, and the air was so lucid that everything could be
seen distinctly through a powerful field-glass. “The sun shone out in
full power,” says Prince Bibesco. “The sun was exceedingly powerful,”
writes Dr. Russell. “The day had become so clear”—he is writing of
the same period as the Prince—“that through a good glass the
movements of individual men were plainly discernible.” And, a little
earlier, he says, “on the hills, through wood and garden,” he was
looking towards the Givonne, “and in the valleys, bayonets glistened,
and arms twinkled and flashed like a streamlet in moonlight.” And so
it continued to the end. “The hills of the battlefield,” writes Dr. Moritz
Busch, “the gorge in its midst, the villages, the houses and the
towers of the fortress, the suburb of Torcy, the ruined [railway]
bridge to the left in the distance, shone bright in the evening glow,
and their details became clearer every minute, as if one were looking
through stronger and stronger spectacles.” Through such a rich and
transparent atmosphere the King gazed from his height upon the city
wherein Turenne was born, in September, 1611, and on the battle
which has made the little town on the Meuse, which Vauban
fortified, still more memorable. A glimpse of the group on the hill is
fortunately afforded by Dr. Russell, whose keen eyes on a battlefield](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-79-320.jpg)
![seem to overlook nothing. “Of the King, who was dressed in his
ordinary uniform, tightly buttoned and strapped,” it is noted that he
“spoke but little, pulled his moustache frequently, and addressed a
word to Von Moltke, Roon, or Podbielski,” who looked frequently
through a large telescope mounted on a tripod. “Moltke,” he goes
on, and the touch is characteristic, “when not looking through the
glass or at the map, stood in a curious musing attitude, with his
right hand to the side of his face, the elbow resting on the left hand
crossed towards his hip.” A picture of Von Moltke, which, taken with
what another observer calls his “refined and wrinkled face,” deserves
to live in the memory. Count Bismarck, we are told, “in his white
cuirassier flat cap with the yellow band and uniform, stood rather
apart, smoking a good deal, and chatting occasionally with a short,
thick-set, soldierly-looking man in the undress uniform of a United
States’ Lieutenant-General.” It was Sheridan. And near these were
many less famous personages, but representative of “all Germany,”
as one writer puts it. On another hill a little further west, whither Dr.
Russell transferred himself, was a second and notable group, which
he sketches. “The Crown Prince with his arms folded, and his flat
cap, uniform frock, and jack boots; Blumenthal so spruce and trim;
half-a-dozen princes and many aides-de-camp” were all sharply and
well-defined on the sky-line. Thus these two groups, “from morn to
dewy eve,” looked down, on, and into a scene which nature and man
had combined to make at once beautiful and sublime.
It was towards the King’s hill that General Reille turned when he
rode out of the Torcy gate. Walking his horse up the steep, he
dismounted, and taking off his cap, presented a letter to his Majesty.
King William, breaking the Imperial seal, read these phrases, which,
if somewhat dramatic, are striking in their brevity:—[1]](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-80-320.jpg)
![days of ceaseless marching and fighting would soon end. As a
contrast to this natural outburst of joy and hope we may note the
provident Moltke, who was always resolved to “mak siker.” His
general order, issued at once, suspending hostilities during the night,
declared that they would begin again in the morning should the
negotiations produce no result. In that case, he said, the signal for
battle would be the reopening of fire by the batteries on the heights
east of Frénois. The return of peace, so fervently desired by the
Army, was still far off in the distance when the tired victors
bivouacked in quiet, and dreamed of home through the short
summer night.
[1] “Not having been able to die in the midst of my
troops, nothing remains for me but to place my sword
in the hands of your Majesty.”
How the Generals Rated each other.
While General Reille, who performed his part with so much
modesty and dignity, rode back over the Meuse, the Emperor still
awaited, in the Sub-Prefecture, the advent of General de Wimpffen,
who was fretting and fuming at the Golden Cross within the walls.
According to his own confession he had become convinced that the
refusal of his sovereign to head a sally from Balan had delivered over
the Army to the mercy of the Germans, and violent despair had
taken possession of his soul. For had not the Comte de Palikao sent
him to overbear Napoleon III. and the set who surrounded him, and
had he not failed to bend the monarch to his will? Twice, he repeats,
with pride, “I obstinately refused to obey” the Emperor’s invitation to
treat with the enemy; and because Napoleon III. had authoritatively
interfered with his command he sent in that letter of resignation](https://image.slidesharecdn.com/1392-250224081142-944e71bb/85/Advances-in-Network-Embedded-Management-and-Applications-Alexander-Clemm-82-320.jpg)
Advances in Network Embedded Management and Applications Alexander Clemm
- 1. Visit https://ebookultra.com to download the full version and explore more ebooks Advances in Network Embedded Management and Applications Alexander Clemm _____ Click the link below to download _____ https://ebookultra.com/download/advances-in-network- embedded-management-and-applications-alexander-clemm/ Explore and download more ebooks at ebookultra.com
- 2. Here are some suggested products you might be interested in. Click the link to download Fuzzy Logic for Embedded Systems Applications First Edition Embedded Technology Ahmad Ibrahim https://ebookultra.com/download/fuzzy-logic-for-embedded-systems- applications-first-edition-embedded-technology-ahmad-ibrahim/ Advances in Management Accounting Volume 13 Advances in Management Accounting 1st Edition John Y. Lee https://ebookultra.com/download/advances-in-management-accounting- volume-13-advances-in-management-accounting-1st-edition-john-y-lee/ Advances in Dynamic Games Applications to Economics Management Science Engineering and Environmental Management Annals of the International Society of Dynamic Games 1st Edition Alain Haurie https://ebookultra.com/download/advances-in-dynamic-games- applications-to-economics-management-science-engineering-and- environmental-management-annals-of-the-international-society-of- dynamic-games-1st-edition-alain-haurie/ Advances in Management Accounting 1st Edition Marc Epstein https://ebookultra.com/download/advances-in-management-accounting-1st- edition-marc-epstein/
- 3. Advances in Nutraceutical Applications in Cancer Recent Research Trends and Clinical Applications 1st Edition Sheeba Varghese Gupta https://ebookultra.com/download/advances-in-nutraceutical- applications-in-cancer-recent-research-trends-and-clinical- applications-1st-edition-sheeba-varghese-gupta/ High Performance Embedded Computing Applications in Cyber Physical Systems and Mobile Computing 2nd Edition Wolf M. https://ebookultra.com/download/high-performance-embedded-computing- applications-in-cyber-physical-systems-and-mobile-computing-2nd- edition-wolf-m/ Advances in Fuzzy Object Oriented Databases Modeling and Applications Zongmin Ma https://ebookultra.com/download/advances-in-fuzzy-object-oriented- databases-modeling-and-applications-zongmin-ma/ Network Management Know It All Sebastian Abeck https://ebookultra.com/download/network-management-know-it-all- sebastian-abeck/ Transforms and applications handbook 3ed. Edition Alexander D. Poularikas https://ebookultra.com/download/transforms-and-applications- handbook-3ed-edition-alexander-d-poularikas/
- 5. Advances in Network Embedded Management and Applications Alexander Clemm Digital Instant Download Author(s): Alexander Clemm, Ralf Wolter ISBN(s): 9781441977526, 144197752X Edition: Kindle File Details: PDF, 1.73 MB Year: 2010 Language: english
- 7. EE E and Applications Advances in Network-Embedded Management
- 9. Alexander Clemm • Ralf Wolter Editors Embedded Management and Applications Advances in Network- Workshop on Network-Embedded Management and Applications Proceedings of the First International October 28, 2010, Niagara Falls, Canada
- 10. Printed on acid-free paper Springer New York Dordrecht Heidelberg London All rights reserved. This work may not be translated or copied in whole or in part without the New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly is forbidden. computer software, or by similar or dissimilar methodology now known or hereafter developed Springer is part of Springer Science+Business Media (www.springer.com) The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are subject to proprietary rights. they are not identified as such, is not to be taken as an expression of opinion as to whether or not Editors Alexander Clemm Los Gatos Kalstert 1446 Cisco Systems 40724 Hilden Ralf Wolter Germany ISBN 978-1-4419-7752-6 analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, e-ISBN 978-1-4419-7753-3 written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, DOI 10.1007/978-1-4419-7753-3 © Springer Science+Business Media, LLC 2011 USA alex@cisco.com rwolter@cisco.com
- 11. Preface It is a great pleasure to present the proceedings of the 1st International Workshop on Network-Embedded Management and Applications, NEMA. NEMA was held on October 28, 2010, in Niagara Falls, Canada, in conjunction with the 6th International Conference on Network and Service Management (CNSM), the former Manweek. It was technically co-sponsored by the IEEE Communications Society and by IFIP. The goal of NEMA was to bring together researchers and scientists from industry and academia to share views and ideas and present their results regarding management (and other) applications that are embedded inside the network, as opposed to merely attached to a network. It is the first workshop dedicated to this particular topic. The also future editions will be announced. The motivation behind NEMA is the general trend of modern network devices to become increasingly “intelligent” and programmable. Examples range from router scripting environments to fully programmable server blades. As a result, networked applications are no longer constrained just to servers that are interconnected via a network, but can migrate into and become embedded within the network itself. This promises to accelerate the current trend towards systems that are increasingly autonomous and to a certain degree self-managing. There are several drivers behind this trend: Equipment vendors continue to add value to the network to counter commoditization pressures. Network and service providers desire to adapt and optimize networks ever more closely to their specific environment. The emergence of cloud in the data center context has provided powerful evidence how programmable networking infrastructure which facilitates automation of management tasks can lead to entire new business models. In addition, there is growing recognition of the importance to make network operation and administration as easy as possible to contain operational expenses, pushing functions into the network that used to be performed outside, and to be able cope with control cycles that need to keep getting shorter from the time that observations are made to the time action occurs. As network devices are being increasingly opened up to in a way that allows them to be programmed, the network itself is becoming a platform for a whole new ecosystem of network-embedded applications serving management and other purposes. The next frontier lies in applications that go beyond traditional management and control functions and that are becoming increasingly decentralized, not constrained in scope to individual systems. Examples include decentralized monitoring, gossip-based configuration, network event correlation inside the network across multiple systems, overlay control protocols, and network-aware multi-media applications. At the same time, another trend looks at leveraging increased programmability of networks, specifically programmability of data and control plane, to add more networking intelligence also outside, not inside the network. This is an exciting time for both researchers and practitioners, as these trends pave the way for another wave of exciting new opportunities for innovation in networking. workshop’s Web site can be accessed at http://nema.networkembedded.org/, where
- 12. The six papers that were selected from the submissions to NEMA represent a wide cross section of varying interpretations of this theme and are divided into two parts. Part One covers enablers for network-embedded management applications – the platforms, frameworks, development environments which facilitate the development of network-embedded management and applications. Starting with the general topic of how to instrument systems for management purposes and transition from legacy command-driven to model-driven architectures, it proceeds with a set of papers that introduce specific examples of hardware- and software based programmable platforms, namely a programmable low-power hardware platforms, as well as an application framework for programmable network control that allows application developers to create complex and application-specific network services. Part Two covers network-embedded applications that might leverage and benefit from such enabling platforms, ranging from the determination of where to optimally place management control functions inside a network, then discussing how multi-core hardware processors can be leveraged for traffic filtering applications, finally concluding with an application of delay-tolerant networks in the context of the One Laptop Per Child Program. We hope that you will enjoy these proceedings and find the presented ideas stimulating and thought-provoking. We would like to thank the authors of the papers without whom the program would not have been possible, the members of the NEMA Technical Program Committees who provided high-quality reviews that enabled us to make the final paper selection from the submissions that were received, and the organizers of CNSM who were hosting NEMA and allowed us to use their conference facilities. In particular, we would like to thank the team at Springer, first and foremost Brett Kurzman, without whom these proceedings would not have been possible and who in many ways got the ball rolling in the first place. August 2010 Alexander Clemm and Ralf Wolter Preface vi
- 13. Table of Contents Preface ……………………………………………………………………………. v Part One: Enablers Chapter 1 Challenges and Experiences in Transitioning Management Instrumentation Sean McGuiness, Jung Tjong, Prakash Bettadapur Chapter 2 Environment ………………………………………………………………………... 19 Pál Varga, István Moldován, Dániel Horváth, Sándor Plósz Chapter 3 Application Framework for Programmable Network Control …………………...… 37 Rudolf Strijkers, Mihai Cristea, Cees de Laat, Robert Meijer Part Two: Applications Chapter 4 Facilitating Adaptive Placement of Management and Control Functions in Converged ICT Systems ………...…………………………………………………. 53 Dominique Dudkowski, Marcus Brunner Chapter 5 Wire-Speed Hardware-Assisted Traffic Filtering with Mainstream Network Adapters ……………………………………………………………………………. 71 Luca Deri, Joseph Gasparakis, Peter Waskiewicz Jr, Francesco Fusco Chapter 6 Embedded Rule-based Management for Content-based DTNs………….…….…… 87 Jorge Visca, Guillermo Apollonia, Matias Richart, Javier Baliosian, í Eduardo Gramp n í from Command-Oriented to Model-Driven ………………..………………………. 1 A Low Power, Programmable Networking Platform and Development
- 14. Contributors Guillermo Apollonia, University of the Republic, Uruguay Javier Baliosian, University of the Republic, Uruguay Prakash Bettadapur, Cisco, USA Marcus Brunner, NEC, Germany Mihai Cristea, University of Amsterdam, The Netherlands Luca Deri, ntop, Italy Dominique Dudkowski, NEC, Germany Francesco Fusco, IBM Research and ETH Zurich, Switzerland Joseph Gasparakis, Intel, Ireland Eduardo Grampin, University of the Republic, Uruguay Dániel Horváth, Budapest Univ. of Technology and Economics, Hungary Cees de Laat, University of Amsterdam, The Netherlands Sean McGuiness, Cisco, San Jose/CA, USA Robert Meijer, TNO and Univ of Amsterdam, The Netherlands István Moldován , Budapest Univ. of Technology and Economics, Hungary Sándor Plósz , Budapest Univ. of Technology and Economics, Hungary Matias Richart, University of the Republic, Uruguay Rudolf Strijkers, TNO and Univ of Amsterdam, The Netherlands Jung Tjong, Cisco, San Jose/CA, USA Pál Varga, Budapest Univ. of Technology and Economics, Hungary Jorge Visca, University of the Republic, Uruguay Peter Waskiewicz Jr, Intel, USA
- 15. Reviewers and NEMA Program Committee Members Raouf Boutaba, University of Waterloo, Canada Marcus Brunner, NEC Europe Ltd, Germany Alexander Clemm, Cisco, USA Waltenegus Dargie, Technical University of Dresden, Germany Metin Feridun, IBM Research, Switzerland Olivier Festor, INRIA Nancy, France Silvia Figueira, Santa Clara University, USA Luciano Paschoal Gaspary, UFRGS, Brazil Lisandro Zambenedetti Granville, UFRGS, Brazil Sven Graupner, HP Laboratories, USA Masum Hasan, Cisco, USA Bruno Klauser, Cisco, Germany Jean-Philippe Martin-Flatin, Consultant, Switzerland John McDowall, Cisco, USA Aiko Pras, University of Twente, The Netherlands Danny Raz, Technion, Israel Jennifer Rexford, Princeton University, USA Gabi Dreo Rodosek, Univ. of Federal Armed Forces, Munich, Germany Volker Sander, FH Aachen University of Applied Sciences, Germany Akhil Sahai, VMware Inc, USA Joan Serrat, Universitat Politecnica de Catalunya, Spain Rolf Stadler, KTH, Sweden Radu State, Luxembourg University, Luxembourg Burkhard Stiller, University of Zurich, Switzerland Carl Sutton, F5 Networks, USA Ralf Wolter, Cisco, USA Xiaoyun Zhu, WMware Inc, USA
- 17. Chapter 1 Challenges and Experiences in Transitioning Management Instrumentation from Command-Oriented to Model-Driven Sean McGuiness, Jung Tjong, Prakash Bettadapur Cisco Systems Inc, 170 West Tasman Drive, San Jose, CA 95134-1706, USA {smcguine, jtjong, pbettada}@cisco.com Abstract. The popularity of model-driven development has grown significantly in recent years pushing its rapid adoption in the management instrumentation space. While standards and tooling have been created for virgin management instrumentation applications, little has been done to address the challenges of transitioning existing applications into the model-driven arena. With management interfaces constructed with divergent stovepipe implementations to meet their differing requirements and data characteristics, moving the entire system to a model-driven environment is an expensive and impractical proposition. Discussed are the design challenges and implementation experiences encountered during the successful transition of a legacy management instrumentation system to a model-driven system, including major design choices and the rationale behind them. oriented, design, development, CLI, SNMP, MIB, legacy, transition 1 Introduction around command-oriented interfaces. As Model-Driven Engineering (MDE) has gained popularity in the management instrumentation community, designers are looking to transition existing command-oriented management where targeted commands have been constructed to directly manipulate or 1 instrumentation applications to MDE-based designs. Transitioning systems Keywords: Management, instrumentation, modeling, command- A. Clemm and R. Wolter (eds.), Advances in Network-Embedded Management and Applications, Historically, much of network management instrumentation has revolved DOI 10.1007/978-1-4419-7753-3_1, © Springer Science+Business Media, LLC 2011
- 18. 2 NEMA Proceedings obtain hard-coded reports of configuration and operational data from specific instrumented features is a challenging proposition. While seemingly model- friendly data-oriented interfaces such as Simple Network Management Protocol (SNMP) exist, these interfaces tend to be confined to data monitoring rather than configuration, provide less functional coverage and are frequently developed as distinctly separate and parallel instrumentation paths from their command-oriented counterparts. Over time, this parallelism degrades the quality, reliability and consistency of the system and complicates transitions to a model-driven design. Inconsistencies across interfaces are demonstrated when data and functions are exposed in one management interface path but not others, like Command Line Interfaces (CLI) providing instrumentation in one form while the same instrumentation is supplied in an SNMP management interface in a different form - or perhaps not at all. Different and multiply redundant instrumentation results in different and redundant request processing, inconsistent request handling, and duplicate configuration synchronization and maintenance requirements. The handling of a CLI instrumentation request, for example, involves certain parameter and system state validation coupled with a specific response however; duplicate constraint validation and default processing can result in inconsistent handling and duplicate maintenance requirements. CLI has one instrumentation data access method while SNMP has another. With duplicated instrumentation access, in order to ensure consistency, quality and reliability, changes to instrumentation data and data constraints, must be applied and tested in all interfaces that access instrumentation. This burden is compounded as instrumentation and management interfaces grow. The introduction of modeling concepts into a system constructed around a command-oriented paradigm will be met with difficulty, as there is a significant impedance mismatch between them. Command-oriented instrumentation uses specific management interface commands tailored for particular features that access data and services directly. Conversely model- driven instrumentation focuses on access to feature data and services through a common abstract interface shared by all management interfaces. Modeled instrumentation describes data and services for all management interfaces. The primary transition problem to overcome is determining the origin of the instrumentation model. One may utilize the characteristics of data and services embedded within the command-oriented implementations; one may create a model based on need and map implementation data and services to it. The choice is hindered by the inherent impedance mismatch introduced by multiple and inconsistent implementations of the command-oriented system
- 19. Transitioning Management Instrumentation 3 and differences between the implicit and imposed models. A model-driven system requires an underlying implementation in order to access instrumentation data and services. This cannot be easily leveraged from the command-oriented implementation due to its parallel nature. Retrofitting model-driven instrumentation on a legacy application constructed with a hard-coded command-oriented instrumentation is difficult. Defining an accurate model based on the actual implementation is the most pressing problem. Designers are faced with the choice of whether to use existing implementations preserving their inconsistencies and redundancies or to address these problems by creating a new streamlined model-driven implementation from their domain knowledge and experience. In this paper the understanding of how management instrumentation system designs are impacted by this transition is discussed. Challenges and experiences will be examined through the prism of a real-world development effort of transitioning a command-oriented management instrumentation system to a model-driven management instrumentation system. The remainder of this paper is structured as follows: Section 2 provides some background on the existing command-oriented instrumentation methodology. Section 3 covers the design considerations for model-driven instrumentation derived from command-oriented instrumentation systems while Section 4 describes key transition implementation experiences. Section 5 covers work in related areas of interest and Section 6 concludes the paper. 2 Background Prior to discussing the transition challenges and experiences, for a better understanding of the problem domain, a brief overview of command-oriented instrumentation methodology is provided. Management Instrumentation interfaces constructed around command- orientation do not typically adhere to crisp layered interface and object- oriented data-hiding principles. Management instrumentation systems often begin with the simplest management method and grow as requirements grow, starting with support of feature-based commands targeted for particular command-line driven instrumentation needs. These CLI interfaces involve the parsing of a user-entered command that link to a monolithic action function. These action functions perform validation of system and feature state and either configure some data or display a hard-coded report describing
- 20. 4 NEMA Proceedings instrumented feature. These action functions are intimately linked with the parse result of their associated command line and the instrumentation they access. The action function for all CLIs that manipulate data and services of a management instrumentation component provide the component’s implicit management model. Transitioning to a model-driven system, designers define and impose a model outside of the command-oriented framework and based on instrumentation domain knowledge and management requirements. They ultimately face the issue of adapting their defined model to the implicit model of the CLI implementation. Difficulties arise when the actual instrumentation capabilities of the implicit model are not reflected in the defined model they are imposing and vice-versa. A similar example of this impedance mismatch can be seen in today’s management instrumentation environment in the area of SNMP MIB support. An SNMP MIB is a model specified outside of the domain of any specific instrumentation implementation. A MIB can specify access to management data and service capabilities that may or may not be reflected in the system instrumentation. Implementers of SNMP MIB interfaces must provide mapping between the imposed model of data and services requested by the MIB and the model implicit in the implementation. Resolving this impedance mismatch – the differences between the implicit and imposed management instrumentation models is perhaps the largest and most complex challenge of the command-oriented to model-driven transition. 3 Design Considerations Model-driven management instrumentation designs are approached from a practical inverse of command-oriented designs due to their focal differences. A command-oriented design focuses on particular management interface commands and their associated instrumentation with respect to a particular feature. Conversely, a model-driven design focuses on the feature instrumentation to be made available for all management interfaces. This section discusses key design considerations when transitioning from a command-oriented to a model-driven design. Figures 1 and 2 below provide a comparison of command-oriented and model-driven architectures. The command-oriented architecture depends upon access to feature instrumentation data being tightly coupled with the management interface. In comparison, the management interfaces of the
- 21. Transitioning Management Instrumentation 5 model-driven architecture utilize a loosely coupled common abstract interface to access feature instrumentation. Fig. 1. Command-oriented architecture showing management interfaces directly manipulating feature data and services. Highlighted is the duplication and coverage between management interfaces. The CLI showing complete coverage, while others less so. Fig. 2. Illustrates how the model-driven architecture abstracts access to instrumentation data and services through a common interface and normalizes data and services availability to all management interfaces. Models in the upper layer describe the management interfaces, while the models in the lower layer provide definitions of the instrumentation they manage. Together, these models describe the management instrumentation of the system in an end-to-end manner. The general architecture of model-driven instrumentation has five primary
- 22. 6 NEMA Proceedings characteristics that should be considered when designing a model-driven architecture based on a command-oriented system. 3.1 Defining the Instrumentation Model The instrumentation model may be defined using either of two distinctly different methods. It may be derived from legacy source code or it may be explicitly constructed based on domain knowledge. Derivation from Source Code In an effort to minimize the impedance mismatch between the imposed model and the implicit model, deriving the instrumentation model from the management instrumentation implementation is often considered by designers. Since the CLI management interface often contains the most complete implementation it is frequently seen as the canonical source for model derivation; however, this task can be wrought with difficulty. Achieving this objective requires correct and complete interpretation of implementation source code sufficient to extract instrumentation configuration data elements, operational data elements, and services. Model element extraction alone is not enough to meet objectives, as the interpretation of the semantic relationship of features, data, and services is also required in the modeled system. Without a perfect interpretation, gaps and model generation errors will require exhaustive human interaction and domain experience to correct. Moreover, it should be carefully considered if the implicit instrumentation model in-fact meets the needs of the target model- driven system. Designing from Domain Knowledge Designing an instrumentation model relies heavily on the designer’s knowledge of the instrumentation domain space. They must understand the configuration data, operational data and services offered by the instrumentation and the relationships between them. If modeling an existing system, it should be accepted that regardless of modeling choices, there is going to be some level of unavoidable impedance mismatch with legacy systems; however, when modeling new instrumentation in the model-driven system, this is not the case. Designers creating models for brand new instrumentation can ensure models have a 100% match to data and services. When constructing model architectures, designers should avoid sacrificing model extensibility by designs that are too rigidly tied to legacy structures.
- 23. Transitioning Management Instrumentation 7 3.2 Model Inheritance When management instrumentation is considered as a collection of models describing the system’s instrumentation, common elements emerge. These common elements may be collected into model libraries for leveraging across instrumentation models. This reduces duplication, streamlines maintenance and helps to promote consistency across instrumentation modeling. Constructed models that leverage a model library may implement or extend it. Derived child models may themselves be model libraries, further extending a reusable model hierarchy. 3.3 Dynamic versus Static Models There are two types of methods for model use in the management instrumentation system – Static and Dynamic. Static models are used at build time to generate source code or other compile-time entities that are fixed in the run-time image. Dynamic models are interpreted at run-time at occasions determined by the management system. If a design is to employ both static and dynamic models, designers must consider what will occur if the model fails dynamic interpretation. How will the model’s availability, as well as its possible dependent libraries be guaranteed? How will version control be enforced? Consider that dynamic models need not only be validated against their dependent libraries, but also against any static libraries used to build the runtime system in which they are being loaded. Designers must take into account the effects of the system’s ability to successfully dynamically load a model in order to function and what affects this may have on system reliability and availability. 3.4 Model Versioning Designs that include models that can implement or extend a model library must also consider management and enforcement of model versioning to ensure compatibility between parent and child models. Defined models must include a mechanism the model interpreter/compiler may use to determine if two models are compatible. In a system that utilizes dynamic models, pre- compiled models must also support version information for system validation during dynamic interpretation. 3.5 Model-Generated Instrumentation APIs Modeled management interfaces obtain and manipulate instrumented features
- 24. 8 NEMA Proceedings through a common abstract interface design. This abstract middleware interface directs instrumentation access requests to appropriate instrumentation for manipulation of data and services through their instrumentation API. The instrumentation API is collection of functions that independently access specific instrumentation data and services. The framework of functions may be generated from information in the instrumentation model, but not the particular code to access the actual data or service of the instrumentation – that must be supplied by the instrumentation developer. When implementing APIs for modeled legacy instrumentation, there are two potential sources for instrumentation API implementation source code: 1) port it from the legacy implementation, 2) write it from scratch. It is important to consider which method is the most accurate, reliable, and most reusable. Frequently, only fragments of command-oriented instrumentation source code may be leveraged in a model-driven design. A careful evaluation of the effort required to port existing code or to write new and perhaps more efficient instrumentation code should be carefully considered. Creating model-driven instrumentation can be more challenging than command-oriented instrumentation development if model-imposed restrictions are to be used. Command-oriented development allows direct and freeform access to feature instrumentation at anytime, from virtually anywhere, with no interface definition requirements. In contrast, because of crisply defined constructs, modeled instrumentation has the capability to ensure rigorous data validation and consistent instrumentation interfaces between clients and available instrumentation data and services. While this makes API definition somewhat more challenging than the freeform method, this is one of the premier benefits of model-driven systems and results in improved reliability and quality. 4 Implementation Experiences This section will explore the challenges and experiences gained through the prism of a real-world development effort where an established command- oriented management instrumentation system was transitioned to a model- driven management instrumentation system. It will discuss design choices and the reasoning behind them. The most design-influential aspect of the transition was resolving the
- 25. Transitioning Management Instrumentation 9 architectural differences between the existing command-oriented system and the target model-driven system. Viewed by many as an inside out to outside in transformation, there were two primary areas that stood out as the biggest hurdles to overcome – instrumentation API development and Instrumentation Modeling. There was considerable effort devoted to developing automated tooling that could minimize the development effort by leveraging existing command- oriented source code to generate candidate instrumentation models and create a basic instrumentation API implementation. In order to perform such a task, the tooling was required to scan and interpret existing source code, derive APIs and candidate models from embedded domain knowledge. These efforts were unsuccessful. Resolution of run-time defined abstract function calls and model semantics proved impractical due to interface complexities and inconsistencies. The end solution was to not transition the command-oriented code and functionality but instead to build a framework that utilized the existing system for existing feature command requests while directing requests for newly implemented functionality to the model-driven framework. This allowed the management instrumentation system to maintain it’s backwards compatibility while at the same time allowing its functionality to grow within the new model-driven paradigm. This coexistence allows existing feature and functionality to be transitioned from the legacy component to the model-driven framework on a piecemeal basis if desired. Maintaining legacy functionality as a coexisting component within the model- driven framework was found to be considerably more efficient, reliable and practical than attempting a manual transition of its entire functional feature set. The second highest design hurdle was the construction and composition of the Model Framework’s APIs. There are two APIs to consider: 1. Middleware Interface API – communicates with management interfaces such as the CLI, SNMP, Syslog and so forth. 2. Instrumentation API – Handles communication between the instrumentation data/services and the Middleware Interface. These APIs must be well considered in order to ensure they satisfy the needs of their users. The Middleware Interface API communicates with management interfaces to supply access to managed instrumentation data and services without tight coupling to the particular kind of feature, instrumentation, data or service being manipulated. A Create Read Update Delete and eXecute (CRUDx) interface was selected to best satisfy the
- 26. 10 NEMA Proceedings abstract needs of the management interface clients. The CRUDx interface provides database-like functionality of management instrumentation resources to client management interfaces. The Instrumentation API has a similar, but slightly more rigidly defined CRUDx interface. This interface definition choice satisfied the middleware layer’s management instrumentation needs enabling it to operate on managed resource instances and on data and services directly. Across both interfaces, request data is passed and response data is returned in a data-oriented fashion. Function oriented APIs were not used as they restrict input/output to the context of the specific function, making them less portable. Data orientation promotes efficient use of individual instrumentation APIs and allows a single request to more efficiently use the services of many different instrumentation components. The third challenge was to determine how to design the system for optimal model management. Examination of the problem domain indicated that there was a large amount of overlap between the instrumentation models and potential for efficient model reuse streamlining both the design and development. Model libraries were defined to promote implementation and extension of common model components. This led to the imposition of model version constraints that impacted model content and how models, model libraries and model elements were referenced by the system. Modeling decisions led to the proposition that the management interfaces could be models and such models could reference instrumentation data and services using abstract identifiers. This broached the subject of dynamic and static model management. Instrumentation models are static, compiled at build-time and are part of the application image. Dynamic models, such as those defining a CLI or an SNMP MIB, may be statically defined at build- time or loaded and compiled at runtime. Faced with the option of utilizing static or dynamic models, a half way solution was adopted. Management interface models were pre-compiled at build-time into quasi-object models moved the compilation and validation step to build time. This optimization enabled the run-time system to perform only the interpretation of validated and prepared pre-compiled models for operation. An API Implementation Example
- 27. Transitioning Management Instrumentation 11 To illustrate the result of some of the API design choices made, a high-level implementation example is provided. For the sake of brevity, a simple Interface Flow Monitor was selected. This component monitors the flow of bytes or packets per second across a network interface and sends and event when a configured high threshold is exceeded. Additionally, it maintains the minimum and maximum observed flow rates and provides the capability to reset this operational data. The model for this component is shown in figure 3. Fig. 3. Illustrates the model of the Interface Flow Monitor component. The Instrumentation CRUDx API generated from the Interface Flow Monitor model is shown below in pseudo code. errorcode createIntefaceFlowProb(Session); value readIntefaceFlowProb_unit(ErrorOut); value readIntefaceFlowProb_highThreshold(ErrorOut); value readIntefaceFlowProb_flowRate(ErrorOut); value readIntefaceFlowProb_minRate(ErrorOut); value readIntefaceFlowProb_maxRate(ErrorOut); errorcode deleteIntefaceFlowProb(); errorcode InterfaceFlowProb_resetMinMax(); These functions have direct interaction with the instrumentation and are called by middleware in response to middleware API originated instrumentation access requests.
- 28. 12 NEMA Proceedings The construct of the middleware API does not depend upon the model, however, the value of arguments passed are model-dependent. For example, the URI arguments in the APIs identify the target object instance to create, read, update, delete or execute. It may also identify a collection of object instances as in the case of a Collection URI (COL-URI) for manipulation of a collection of objects and data. The DataIn and DataOut arguments signify the variant types of data that may be passed between the client and the identified target object(s). The middleware API is illustrated below in pseudo code. errorcode create(URI); errorcode readConfigData(DataOut, URI); errorcode readOperationalData(DataOut, URI); errorcode updateConfigData(DataIn, URI); errorcode delete(URI); errorcode execute(DataOut, DataIn, URI); When the middleware receives a call across this interface, it resolves the URI to the object instance and performs the associated Instrumentation API call for the entity. readOperationalData(long& lRate,”/services;servicename= /IFFlowMon/probes;id=/Q/flowRate” ); The middleware resolves this information to a call to the instrumentation API shown here in trivial pseudo code: Q=get(”/services;servicename=/IFFlowMon/probes;id= /Q”); lRate=Q->readIntefaceFlowProb_flowRate(ErrorOut); While most of the fine details of the middleware and instrumentation API interactions have been excluded, the example illustrates the design choices and resulting concepts of middleware and instrumentation API construction from the instrumentation model. 5 Related Work There is a great deal of work that has been done in the area of Model-Driven Engineering (MDE) over the past three decades and was crystallized with the formation of the Object Management Group (OMG) [10] in 2001. The OMG was formed to establish modeling and model-based standards. Since that
- 29. Transitioning Management Instrumentation 13 time, the promises of MDE have been elucidated for the development of new applications, providing modeling tools, development tools, domain specific languages, and the like. A virtual plethora of standards and applications have been created to support the development of new model-driven applications, however little has been done to address the cost effectiveness of leveraging existing systems in a model-driven environment. Douglas Schmidt [4] in his February 2006 Model-Driven Engineering overview states “When developers apply MDE tools to model large-scale systems containing thousands of elements, they must be able to examine various design alternatives quickly and evaluate the many diverse configuration possibilities available to them.” He refers to the Integrated Modeling Approach of Lockheed Martin Advanced Technology Laboratories as an example of legacy integration with less than ideal results: “Reverse engineering is used to build models… from existing source code. Many previous attempts to reverse-engineer models from source code have failed due to a lack in constraining aspects of interest.” A similar experience described in this paper. In his article “The Pragmatics of Model-Driven Development”, Bran Selic[6] discusses legacy integration mostly in terms of development tooling only tangentially touching upon the issue of leveraging application source code in the modeled environment. In this case, the recommendation was to take advantage of legacy code libraries and other legacy software where domain-specific knowledge often resides. While certainly true, this view overlooks the problems of impedance mismatch between the two designs and often-prohibitive implementation cost of custom glue code. At the UML Conference of 2003, Jean Bezivin [2] presented “MDA: From Hype to Hope, to Reality” where it was stated: “The extraction of MDE- models from legacy systems is more difficult but looks as one of the great challenges of the future. There is much more to legacy extraction than just conversion from old programming languages”. Indeed, it is the variability of legacy systems, platforms and ultimately the model impedance mismatch that is at the heart of these challenges. Unfortunately, most work in the Model-Driven Engineering area focuses on the rapidly accelerating model-driven technologies and patently avoids dealing with the big white elephant in the middle of the room – how to leverage the existing application features and functionality in an efficient and cost-effective manner.
- 30. 14 NEMA Proceedings 6 Conclusions Management instrumentation designers are looking to shift their command- oriented management instrumentation to model-driven in order to utilize the benefits of these modern technologies but are daunted by the difficult challenges that complicate such a transition. Features supported through stovepipe CLI implementations and augmented with redundant and often only partial, alternate management interfaces complicate the problem. The practice of feature-specific/command-oriented implementations, while freeform in construct, culminates in multiple and redundant request handling, inconsistencies between management interfaces and differences across product versions. Perhaps most significantly, it geometrically increases maintenance requirements and costs due to duplicate and redundant code. Designers considering a transition to a model-driven system will find this impedance mismatch to be the most vexing problem. In an ideal scenario, designers would like to leverage legacy code in the model-driven system by deriving models directly from the legacy source code, however this is seldom possible. The tight coupling of individual management interfaces with manipulated instrumentation data and services fundamentally blur the lines between the models they desire and the models implicit within their implemented instrumentation. This makes model derivation from legacy source an impractical proposition. Experience has shown that neither reverse engineering nor model- derivation met expectations, but rather integrating a legacy system as a coexisting component was found to be the most desirable solution. Instead of attempting a re-design or fully modeling a seasoned management instrumentation system, the system itself was leveraged as an integrated partner of the model-driven framework. This technique allowed the supply and maintenance of existing features to the system while at the same time promoted the development of new features and functionality within in the model-driven framework. The successful transition of a command-oriented system to a model-driven management instrumentation framework supporting both management interfaces and instrumentation involved the resolution of several key design considerations surrounding API development. Management interfaces reside above the middleware layer and exist in the management domain, requesting instrumentation data and services from the middleware interface as clients. Client services available from this interface are accessed in a manner decoupled from the instrumentation implementation using functions that provide well-known Create Read Update Delete and eXecute (CRUDx)
- 31. Transitioning Management Instrumentation 15 capabilities. Similarly, the middleware communicates with instrumentation implementations using a more rigidly defined model-generated CRUDx API that operates directly on an instance of the instrumentation object, invisible to management interfaces. Significant in the design of these APIs were their construction. Decisions that request data would be passed across each interface affected the kind of API generated. The API exposed to management interfaces is data oriented in order to facilitate optimal communication between management agents and middleware. The Instrumentation API required similar exposition of data and services for direct operational performance on an instrumentation instance by middleware. Scrutiny of the instrumentation modeling problem domain revealed a large overlap of common elements among instrumentation models. Model leveraging was introduced using model libraries to share common components among models and model libraries allowing extension and implementation promoting model reuse. This concept further revealed the need for model and library versioning to ensure the integrity of referenced models during compilation and interpretation. As the implementation of modeling paradigms took hold, the concept of utilizing modeling to describe management interfaces became clear. Modeling management interfaces utilizing instrumentation models to connect management elements to associated instrumentation data and services promoted an end-to-end management instrumentation development paradigm. This opened the door to dynamic model management – the idea that a management model did not have to be built within an application, but could be installed or removed in a running system dynamically. After considering dynamic build and interpretation options, designers chose to dynamically load pre-compiled/validated models. This design choice minimized the runtime compilation and validation burden on the running system and promoted better dynamism of the management interface models. When faced with the daunting task of moving a command-oriented system to a model-driven paradigm, the impedance mismatch is at the heart of the matter. Finding a way to bridge the gulf the between the traditional “top- down” view and the modern “everything is an object” view is the crux of a successful transition. Further Work The transition factors highlighted herein focused on the primary design and implementation considerations. Additional work should be done to illustrate the details of integrating an existing management instrumentation system as a
- 32. 16 NEMA Proceedings coexistent component in a model-driven framework, covering details of the glue-logic and model-driven interactions. Moreover, the concepts developed for code generation from models should be provided to describe the techniques developed through the experience to provide end-to-end round trip model, code management and synchronization. Finally, and perhaps most importantly, the impedance mismatch between the command-oriented and model-driven paradigms are not restricted to design, but extend to development processes as well. The experience yielded significant changes to existing command-oriented development processes and involved much work with human factors engineering resulting in new, optimized processes requiring developer management and acceptance. All of these areas are in need of further research. References 1. Poole, J. D.: Model-Driven Architecture: Vision, Standards and Emerging Technologies, ECOOP, Workshop on Metamodeling and Adaptive Object Models (2001) 2. Bezivin, J.: On the Unification Power of Models, MDA: From Hype to Hope, and Reality, UML Conference, San Francisco (2003) 3. Tolvanen, J.P.: Making model-based code generation work, Embedded Systems Europe, Aug 2004, 2010) 4. Schmidt, D. C.: Model-Driven Engineering, IEEE Computer, Feb 2006, 5. Brown, A.: An Introduction to Model-Driven Architecture, IBM Technical Library, http://www.ibm.com/developerworks/rational/library/3100.html 2010) 6. Selic, B.: The Pragmatics of Model-Driven Development, IEEE Software 2003, http://www.cs.helsinki.fi/u/przybils/courses/CBD06/papers/01231146.pdf (retrieved 2010) 7. Daniels, J.: Modeling with a Sense of Purpose, IEEE Software, Jan 2002, http://www.syntropy.co.uk/papers/modelingwithpurpose.pdf (retrieved 2010) 8. Bezivn, J., Gerard, S., Muller, P-A., Rioux, L.: MDA Components: Challenges and Opportunities, 2003, http://www.sciences.univ-nantes.fr/lina/atl/www/papers/MDAComponents- 9. Almeida, J.P.A: Model-Driven Design of Distributed Applications, http://i.cmpnet.com/embedded/europe/esesep04/esesep04p36.pdf (retrieved http://www.cs.wustl.edu/~schmidt/PDF/GEI.pdf (retrieved 2010) (retrieved ChallengesOpportunities.V1.3.PDF (retrieved 2010)
- 33. Transitioning Management Instrumentation 17 Telematica Instituut Fundamental Research Series, No. 018, 2006 10. Object Management Group, www.omg.org
- 35. Chapter 2 A Low Power, Programmable Networking Platform and Development Environment Pál Varga, István Moldován, Dániel Horváth, Sándor Plósz Budapest University of Technology and Economics Inter-University Cooperative Research Centre for Telecommunications and Informatics, Magyar Tudósok krt. 2, H-1117 Budapest, Hungary {pvarga, moldovan, horvathd, plosz}@tmit.bme.hu Abstract. Programmable networking platforms are getting widely used for customized traffic manipulation, analysis and network management. This propagates the need for exceptional development flexibility, for wide variety of high-speed interfaces and for the usage of high performance, yet low power technologies. This paper presents an FPGA-based programmable platform, capable of real-time processing, filtering and manipulating 10Gbps traffic. In order to expand its potential, besides the two 10GbE interfaces, the platform contains extension slots for COM express, mini PCI-e, and it has 16 onboard SFP connectors, towards which the fraction of the traffic, or even the full traffic can be forwarded to. The design is modular, programmable in both hardware (firmware) and software, aiming low power consumption. The full potential of the hardware can only be exploited with an easy-to-use development environment, with simple design customization and support for creating new applications. To fulfill this, a development environment is also presented, including a modeling framework that provides an easy way to create new networking applications on the platform. This framework allows modeling applications in SystemC, and eases the development of the hardware description code. Keywords: 10GE, programmable platform, DPI, FPGA, low power A. Clemm and R. Wolter (eds.), Advances in Network-Embedded Management and Applications, 19 DOI 10.1007/978-1-4419-7753-3_2, © Springer Science+Business Media, LLC 2011
- 36. 20 NEMA Proceedings 1 Introduction Networking at ever growingly high-rate connections constantly generates challenges for researchers and engineers developing algorithms and equipment to handle the demands of networking services. The increasing rate is not the only concern, but it brings some general, seemingly far-away problems into the limelight. When data arrives to a system at 10 Gigabit per second rate, the time is very limited for analyzing or handling it. Moreover, there is no point for its single storage for further analysis (except for some targeted analysis). If the system cannot process continuously arriving data, it will not be able to process it later, when further data still arrives continuously. To optimize data processing in many levels, tasks should be distributed and made parallel. The processing level here does not only mean OSI levels, but levels of processing complexity determined by the given task. Examples for such tasks are flow assembly based on TCP- and IP-headers, routing and switching between interfaces, application classification by using DPI (Deep Packet Inspection), etc. Our system utilizes multiple processors with various capabilities for processing network traffic in various levels. The capabilities on the main board are distributed through FPGAs (used for time-stamping and initial packet header processing) and a general processor (used for management functions, and basic traffic analysis, statistics creation). Processors on the COM express PC and the PCIe-connected modules can be utilized for complex processing, including routing, switching and basic DPI. Furthermore, the system is prepared for very complex DPI (application analysis through fingerprints, deep flow analysis, etc.), by means of streaming digested packet and flow-data to external processors through its 1GbE interfaces. Low power design is a current and very important requirement in all fields, including IT systems. The high demand for networking services is covered by ever increasing number of servers and networking equipment, which, if left uncontrolled, waste electrical power and simply turns it into heat. On the other hand, handling or analyzing high speed traffic requires high performance, which is by definition a term competing with low power consumption. The challenge of high-performance, yet low-power systems is to find out which costs less power: should we shut down resources that are not in use and urgently wake them up when required or should we leave the resource running. Measuring power consumption and optimization for low power with high performance was a very key requirement during the definition and design of our system. We have also created a development environment together with the platform. The aim of this is to accelerate the development process of network applications on FPGAs in general. The environment provides a GUI and a set of hardware modules which builds up a variety of network devices. Key use-
- 37. Low Power, Programmable Networking Platform 21 cases are switching, routing devices, NAT devices, firewalls, deep packet inspectors, and traffic loopback devices. The system has been designed and developed by applying a close hardware-software co-design methodology. This primarily defined the distribution of tasks among the various types of processors. Beside, this flexibility allowed the clarification of basic processing modules and algorithms, which enabled to create a programmable networking platform. For design space exploration and to validate the design, a SystemC [1] based modeling environment is used. The results of the SystemC modeling can be used to construct the final hardware models and the corresponding software. The SystemC hardware components are also available in generic hardware description language (Verilog/VHDL) making the synthesis of the hardware possible. The developers will also be able to generate the top-level hardware model through the GUI. The modules required for the generic networking applications have been selected by identifying the most important use cases. After the literature survey in the next chapter, we briefly describe the hardware, the firmware, and the development environment to be used for various networking applications hosted by the platform. Afterwards we highlight the usability of the environment through two use-cases: a network monitoring DPI scenario and a routing/switching scenario. 2 Related Work In the literature, we have found similar work dealing with packet processing on FPGA-based systems. Besides the industry leading Endace DAG packet capture products [3], the NetFPGA [4] platforms are largely in use in academic research to test for ideas and implement them on flexible hardware. The TenGig NetFPGA card is currently under development, and it will be capable of 10G traffic handling. It will provide 4 XFP ports RLDRAM II, QDRII, SRAM, PCIe 8x interface and extension connector, powered by a large Xilinx Virtex-5 FPGA, XC5VTX240T which is quite expensive. A similar platform is developed within the Cesnet Liberouter project [5], which already provides a 10G extension card to their extensible Combo system, making it capable of 10G packet processing. We would also mention an interesting application of FPGA-based design platforms for Gigabit Ethernet Applications. FPGA-based implementations offer the possibility of changing the functionality of the platform to perform different tasks and high packet-processing rate capabilities. In particular, the authors of [6] proposed a versatile FPGA-based hardware platform for Gigabit Ethernet applications. By introducing controlled degradation to the network traffic, the authors provided an in-depth
- 38. 22 NEMA Proceedings study on real-application behavior under a wide range of specific network conditions, such as file transfer, Internet telephony (VoIP) and video streaming. Other approaches include hardware accelerated routing, e.g. the work of D. Antos et al. [7] on the design of lookup machine of a hardware router for IPv6 and IPv4 packet routing with operations are performed by FPGA. In this framework, part of the packet switching functionality is moved into the hardware accelerator, step by step. This allows keeping the complete functionality all the time, only increasing the overall speed of the system during the whole development process. D. Teuchert et al. [8] also dealt with FPGA based IPv6 lookup using a pipelined, tree-bitmap algorithm based method. The NetFPGA project also provides a development environment for the programmable hardware platform. Their approach [10] is to provide reference architectures (interface card, switch, router, etc.) as starting points for new development. To avoid the necessity of hardware level programming and provide a high level interface, a framework is presented in [11] to incorporate hardware G modules into NetFPGA based system designs. Although there are several similar approaches [9], none of them fulfills the requirements of the C-Board. The existing hardware is not fast or not scalable enough, while also the development environment lacks the flexibility and the required simplicity. 3 The SCALOPES C-board The ARTEMIS SCALOPES project aims at developing and utilizing novel methods in low power, high performance embedded platforms. Our SCALOPES C-board is the prototype platform for the communication infrastructure-related applications inside the project. The main purpose of the C-board is to provide a basis for high-speed data processing and manipulation. It could either host or serve monitoring, switching, routing, filtering and other applications that require real-time processing of 10 Gigabit Ethernet traffic. In the following sections the motivations, requirements and the state of the art is surveyed, followed by the brief description of the architecture. 3.1 Motivation and Requirements Real time analysis and manipulation of 10 Gigabit Ethernet traffic requires scalable, high performance equipment. Clear and easy-to-use management and programming interfaces further ease the task of the user of such equipment. There are some programmable networking platforms already
- 39. Low Power, Programmable Networking Platform 23 available in the field, nevertheless, upto this date we have not found another platform that - is both programmable in hardware and software, - can manipulate the traffic by utilizing PCIe-connected controllers, - has capabilities to directly forward 10Gbps Ethernet traffic to/from 1Gbps Ethernet or SONET, - is designed for measurable low power consumption, and - has lowered risks for extra developments since composability, predictability and dependability [2] issues are tackled. The SCALOPES C-board was designed and developed with the ultimate intention of putting the above requirements into practice. 3.2 Internal Structure The practical capabilities of any networking equipment are limited by its internal elements, their programmability, and its interfaces’ types, modes, and speed. During the development of the SCALOPES C-board, the requirements were set high: it is a highly scalable device with a well-defined programming toolchain, capable of manipulating traffic arriving from SONET, ATM, Gigabit and 10 Gigabit Ethernet, routing/switching the traffic between these interfaces and further controlling or processing it through PCIe x4 extension modules. The simplified architecture of the board is depicted by Fig. 1. The main components of the device are the following: - XFPs (10 Gigabit Small Form Factor Pluggable Modules) connecting to XAUIs (10 Gigabit Attachment Unit Interface) for 10 Gbps traffic reception, - SFPs (Small Form/factor Pluggables) to handle various Gigabit Ethernet ports, for output to devices, - four FPGAs (Field-Programmable Gate Arrays) connected in a matrix, used for packet capture and manipulation, including interface handling, traffic flow handling firmware blocks, basic statistical modules, - memory for packet buffering and flow tables, - extra processor for on-board processing and management software, - redundant power supply.
- 40. 24 NEMA Proceedings Fig. 1. The simplified structure of the SCALOPES C-board Each element of this architecture meets the basic dependability requirements in order to support the overall dependability/survivability of the system that it is part of. The main part of the device is the FPGA matrix (or ring), containing four FPGAs. The FPGA technology helps building a multi-purpose hardware. A great advantage of this technology is that a simple firmware switch enables us to switch between applications much faster than if we needed to switch the whole device. The outside interfaces (SFP, XFP and COM express slots) connect to the FPGA’s RocketIO ports, which allow high speed communication between interfaces. The optional variation of interfaces (Gigabit Ethernet optic, 10/100 Ethernet, STM-1 optic etc…) is possible by using SFP module receivers. The physical and logical connection between the interfaces is defined by the FPGA firmware ensuring the hardware’s flexibility. The current firmware is physically stored on flash memory connected to the chips: they load as soon as the hardware starts. I/O data is shared between FPGAs through a dedicated communication ring interface. There are two rings defined by the clockwise and counter-clockwise direction of communication, assigned to the two 10 Gigabit Ethernet interfaces. Fig. 2 depicts the architecture of the board and the connection of the FPGAs.
- 41. Low Power, Programmable Networking Platform 25 Fig. 2. Internal structure of the SCALOPES C-board and the two-way communication of the FPGAs There is an additional interface designed for configuration and maintenance. The FPGAs can be reprogrammed during operation, and the running IP-core can be controlled/changed through a 10/100 Mbps Ethernet interface connected to the COM express PC. 3.3 Low Power Design During the development of the C-board, one of the main, higher goals was to create a device of low power consumption. Depending on the network configuration, the used application and the traffic volume the power consumption of the C-board becomes significantly lower in comparison to systems that do not use sophisticated power control. As a static requirement, it can be reached by using low-power electronic elements. The operating power
- 42. 26 NEMA Proceedings consumption depends on the clock frequency as well. The C-board is configured to operate on the lowest frequency on which it is able to process all of the traversing packets on 10 Gbps interface. Furthermore, lower power consumption can be reached by close power control of the programmable devices in a dynamic manner, while they operate. There are three areas in the SCALOPES C-board where such Dynamic Power Control (DPC) can be administered: the interfaces, the FPGA and the memory. DPC is managed by a central resource manager (governor) application, residing in the compact PC. Naturally, if an Ethernet interface is not configured to be working in a given configuration (runtime), its controller is shut down, not consuming any power. Moreover, the Ethernet interfaces connect to the FPGA chips in a distributed manner, which means if the related interfaces are not needed, the corresponding FPGA chip can be assigned to stand-by mode, hence significantly decreasing the system’s energy consumption. This power reduction scheme can be initiated runtime, in connection with the network configuration changes. Internally to the FPGAs, power islands are defined for segregated functions: interface handling, packet filtering modules, management modules and low-speed/high-speed implementations of packet processing algorithms (depending on timing criteria, the low-speed implementation might be used for power considerations). Based on the running application and the traffic volumes the central power governor can decide to shutting down or waking up these islands. DDR RAM memory is connected to the FPGAs, and its power- management can also be controlled from there, runtime: it can be set to stand- by or power down mode if a given application does not need to use the external memory. In order to measure power consumption, sensors are placed at key areas of the hardware. These sensors send signals about the measured signals to the management interface, where the data can be collected, analyzed and used for system tuning. 4 The Development Environment Developing or even modifying complex networking systems that consist of hardware and software processing modules require either incredible experience or extreme braveness – sometimes both. In order to develop applications to the SCALOPES C-board, efficient hardware and software co- design methodology must be administered. Our approach follows a two-step process in the high-level, and based on elemental building blocks of a modular architecture. The first step in the
- 43. Low Power, Programmable Networking Platform 27 process is the development of simulation models, from the modeling blocks available or ready to be developed. The second step in the process is the actual hardware and software design, based on the experiences gathered from the modeling evaluation. This process requires both less experience and less braveness from the developer, since on one hand the building blocks already provide some design security, and on other hand he or she is going to be supported by the understanding the possible obstacles after learning the simulation models. Fig. 3 depicts the development environment from a high- level perspective. The flexible programming capabilities provided by the SCALOPES C- board’s processors and interfaces can only be exploited if a well-defined firmware development environment accompanies the device. Experience in HDL programming may be a serious limiting factor for customized system enhancements that require firmware development. Hardware, firmware and accompanying software programming knowledge is rarely present together in an organization that is not specialized exactly for these – and utilizing only one of these essential capabilities when experimenting with the networking platform leads to suboptimal results.
- 44. 28 NEMA Proceedings The development environment consists of a modeling environment, where the application is modeled in SystemC, and a hardware/software co-design methodology, utilizing commercially available programming tools as well. The development environment gives access for different levels of complexity, from basic GUI-based modifications to full simulation/modeling and co-design. 4.1 GUI based development Starting from a provided generic application architecture, custom firmware can be easily generated using available “filters”. There are several generic modules available for packet manipulations that can be inserted at the packet input/output processing stages of the architecture. These modules may also provide a software interface, for setting filter rules, reading statistics etc. For example, a simple firewall can be created by adding input and output filter blocks to the generic packet forwarding application. Adding NAT functionality means inserting a NAT module at the egress interface. Fig. 3 shows the structure of the development environment. The whole development process can be done using the provided GUI. The GUI is written in Java, integrates the tools into a development environment and provides editing functions. The available modules are described in IP-XACT [12] XML format, and they can be selected from the toolbox and with simple drag- and-drop operations they can be inserted in the architecture. Composability is ensured by using the IP-XACT specification format, and is automatically checked while connecting the interfaces. Both the SystemC and VHDL sources for the different modules are also provided, along with their IP-XACT description. The new design can be tested by the SystemC simulation framework, which provides traffic generators for performance testing and predictability analysis. The top-level HDL file is generated automatically based on the connections made on the GUI, and the final firmware can be synthesized using the Xilinx ISE. As the new application is a modified version of the generic application with filter components added, its performance should not change, only an insignificant the latency is introduced by the filters. Besides the composability checking, a dependability and predictability analysis is also possible. The framework will be extended to generate a Continuous Time Markov Chain (CMTC) based dependability model of the system stored in a view in the IP-XACT description, which can be used in open-source simulators like the PRISM model checker [13]. A queuing model of the hardware can also be created, which makes possible the analysis and queue dimensioning for different traffic mix scenarios.
- 45. Low Power, Programmable Networking Platform 29 4.2 Custom module development The development of the new applications is also assisted by a number of available hardware component models that can be used for generic networking application development. The already available components define a generic packet processing/forwarding architecture with extensible filtering and processing properties, and a generic deep packet inspection architecture. All components come with SystemC and VHDL source code and IP-XACT description. The extensible, modular architectures are designed to allow easy integration of application-specific header operations at the ingress and egress. A method for buffering the packet payload is also provided. Most of the applications can be covered with the available modules. The architecture also features a hierarchical power management concept for low power operation [14]. However, if a custom module is needed for a hardware-level operation which is not yet available, new modules can be created and added to the model database by adding the source files to the SystemC and VHDL directories and creating the IP-XACT XML descriptor. The key issues are the interfaces of the new component, and the timing requirements. For the most common operations like input/output processing and flow handling well defined interfaces are provided with low timing requirements. However, for line-speed processing all modules must handle back-to-back packet arrivals at interface speeds. For even easier development generic filter prototypes are provided with full source code. First, the SystemC model should be created, for composability and predictability checking. Based on the SystemC model the HDL model can be created too, and added to the HDL model database. 4.3 Hardware accelerator development The protocol processing task usually starts with basic input/output operations like packet reception and queuing. These operations require hardware processing, for fastest execution. After several stages of header processing, it may not be suitable for hardware processing because of increased complexity; software processing is more flexible and desirable. The conventional networking protocols had simple structure, binary headers and fixed fields. As we climb the levels of the OSI model, the protocols become more and more complicated, with variable header lengths and fields. One of the most difficult protocols to decode are the textual protocols like HTTP and SIP, where very few things are fixed, fields can be mixed, string identifiers are used and all fields have variable length. Such protocols require software processing, involving parsing. There are several methods to enhance the processing in hardware with accelerator interfaces. Different protocols require
- 46. 30 NEMA Proceedings different interfaces, possibly tailored to the given application. Unlike for network processors, where hardware accelerators are given, we can design and implement custom hardware accelerators in order to achieve best performance. There are several hardware accelerators that are generic, like binary/ternary CAM tables, queue managers etc., but accelerators can be tailored by an optimization process. In our approach we consider that processors can reach the hardware accelerators through a simple and fast interface, like port I/O operation or memory operation to a very specific area. The optimal separation of software/accelerators/hardware however is an optimization “knob” that requires an iterative approach to select the optimal parameters. A further gain for the hardware acceleration is the decreased power requirement, since hardware processing has lower cost form the point of view of energy consumption.
- 47. Low Power, Programmable Networking Platform 31 5 Case Studies The platform itself is capable of high-speed packet processing but can be extended with industrial PC boards for complex functions and increased processing power. Therefore it can perform all network related functions from the low level high-speed packet forwarding to the most complex protocol processing. These packet processing architectures also utilize powerful energy management techniques. First, power islands can be formed, and unused islands may be powered down. Furthermore, local power management is used where possible by turning on the processing modules only if they are needed. Finally, a central manager provides a management interface for the control of the power islands. In the following we present several specific use cases for the SCALOPES C-board. 5.1 A Network Monitoring System with DPI Capabilities Traffic monitoring plays an important role in network management, network optimization and planning. Operators are usually aware of only the main characteristics of the traffic, which generally is limited to an average throughput with 1-minute granularity. On the other hand, information about fine granularity of the traffic allows for network tuning and more effective planning. As the operators switch to 10GbE connections, processing packets and flows real time at this speed is getting more and more important - no matter how complex this task really is. Deep packet inspection and flow analysis cannot be carried out with on this rate by using the currently available processors and memories, hence the traffic is going to be filtered and distributed over several processors outside the C-board for full analysis. In this use-case we present a monitoring system capable of DPI at line speed. Furthermore, we show that using our easy development environment the DPI can be easily tailored to the specific requirements. The high-level workflow of DPI and flow analysis in this system works the in the way depicted by Fig. 5. The C-board receives the monitored traffic through the 10Gbps XFPs, and initially timestamp each packet. Depending on their configuration, the filter modules pass “interesting” packets to the forwarding buffer, and sends these to flow classification with the rest of the traffic. The classifier puts together flows based on the packet
- 48. 32 NEMA Proceedings Fig. 5. DPI firmware architecture headers. The flow analysis module provides statistics with fine granularity, and application identification information on each flow. The flow data and the chosen, “interesting” packets get forwarded from the buffer, through the output selectors to further processing entities over the 1Gbps Ethernet channels. These processing entities are PCs called “Monitor Units” with high processing and storage capacity. In order to reduce loss of data between the outsider processing entities and the C-board, the packet information (headers and predefined parts of the body) get encapsulated in TCP flows and then forwarded. TCP is needed in order to assure lossless transfer of capture-data towards the remote units. The Monitor Units carry out complex traffic identification and traffic matrix analysis, as well as store bit-by-bit packet header information if configured so. The basic DPI requires a specific firmware architecture, where the traffic is flowing from the XFPs towards the classifiers from where it will be de- multiplexed to 1Gbps speed. The complex DPI algorithms run on the Monitor Units. The architecture shows the basic internal architecture for DPI application. The first and most important “knob” is the flow classifier. Several methods can be used, for example IP address range based, TCP/UDP port based, etc., selecting different portions of the traffic for deep inspection. It is even possible to configure the flow classifier from software, selecting the hardware filtering rules easily. Further user-selectable items are the statistic flow analysis modules. According to the required set of flow information, specific filters may be inserted in order to get the required information.
- 49. Low Power, Programmable Networking Platform 33 The C-Board with the DPI firmware architecture is capable of monitoring full speed the 10Gbps traffic in both directions, and it can forward it to the SFP interfaces without packet loss. Finally, in a realistic use-case a part of the traffic can be streamed to the SFPs for packet level analysis. Up to 8 Gbps traffic can be streamed to the receiving monitor PCs dependably [13]. 5.2 Generic Switch/Router architecture The SCALOPES C-Board can also be used as a generic Switching/Routing architecture with hardware level packet forwarding. The architecture supports two 10 GbE ports, 16 GbE ports with an arbitrary combination of SFPs. Fig. 6. Generic Packet forwarding architecture The used packet processing pipeline is similar to the model recommended by Xilinx [15] and the model used by the Liberouter project [5]. The packets are filtered first, then all traffic is written in the DDRAM for buffering. Since the memory access can be the bottleneck in our packet processing pipeline, we tried to avoid copying the packet. We have decided to use the shared- memory packet forwarding model, this way avoiding unnecessary copying of data. The model has a further advantage: even multicasting/broadcasting can be done without actually copying the data. The generic packet forwarding architecture is shown by Fig. 6. The arriving packets are buffered, while their header information is however forwarded to the lookup module. The lookup module is responsible to decide on which interface the packet should leave. For flooding, broadcast and multicast multiple interfaces may be selected. For different application types, different routing/switching modules can be designed, which may operate at different layers of the OSI model, like L2 switching, IPv4 or IPv6 routing, MPLS packet switching etc. Based on the decision at the lookup module, a short
- 50. 34 NEMA Proceedings internal header information is written in the egress interface queues (multiple queues in case of broadcast/multicast packets). The output filter block is responsible for scheduling and queuing, and retrieval of packet data from the DDRAM and transmitting on the egress interface. The performance of this architecture is only limited by 2 main factors: lookup speed and DDRAM access. The lookup speed depends on the L2 or L3 forwarding table size and lookup algorithm, while DDRAM access may introduce delays in case of small packet sizes. The generic packet forwarding architecture can be extended with a COM express based PC board, providing considerable processing power. This extension opens up further application possibilities for the board. Such a possible application is a Session Border Controller. Session Border Controllers (SBCs) have evolved to address the wide range of issues that arise when voice and multimedia services are overlaid on IP infrastructure. These include a wide range of operations from packet level monitoring tasks through flow level manipulation tasks to high level signaling processing tasks, all at high speeds. These put high demand on both hardware and software. With our C-board extended with a PC board a high performance SBC can be designed. The key idea in this use case is the close interworking between the software processing on the PC board and hardware processing on the FPGA board. The low level processing handles the high-speed traffic and passes only the network signaling traffic to the processor. The routing protocols and forwarding control can be done just like in the previous case. An open protocol like OpenFlow [16] can be used to control the hardware flow processing. 6 Summary The SCALOPES C-board is a versatile programmable platform capable of handling 10Gbps Ethernet traffic. It provides a base platform for various packet processing applications such as switching, routing filtering, monitoring, etc. Its modular structure allows its extension with processing cards to increase its applications with high-speed software processing as well. The C-board is accompanied by a development environment to unlock its full potential. The environment supports the development process from design-space exploration and modeling in SystemC to modular design. It is based on predefined hardware modules, from which the basic applications (packet forwarding, DPI) can be constructed. The development environment will also feature a graphical user interface, providing easy development for customization. The scalability and low power requirements have been taken into consideration for both hardware and software design. We have demonstrated some major application fields for the hardware on use cases.
- 51. Another Random Scribd Document with Unrelated Content
- 52. next steps which should be taken.” It was a notable meeting, and few words, indeed, were required to indicate the finishing touches of an enterprise, so unexpectedly imposed on them, and so resolutely carried out by these skilful, far-seeing, and audacious captains. They had come to the conclusion that the French had before them only one of two courses—they must either retreat bodily into Belgium, or sacrifice the greater part of their Army in an endeavour with the remainder to reach Paris by way of Mézières. There was a third—to remain and be caught—but a finis so triumphant was not foreseen by the trio of warriors who met in the village of Chémery.
- 53. PLAN VI: BATTLE of SEDAN, ABOUT 10. A.M. Weller & Graham Ltd . Lithos. London, Bell & Sons The Battlefield of Sedan. The battlefield of Sedan may be described as the space lying within the angle formed by the Meuse, and its little affluent, the Givonne, which flows in a southerly direction from the hills near the Belgian frontier. After passing Bazeilles and its bright meadows, the greater river meanders towards the north-west, making, a little
- 54. below Sedan, a deep loop inclosing the narrow peninsula of Iges on three sides, and then running westward by Donchery, Dom le Mesnil and Flize to Mézières. From the northern end of the loop to the Givonne, the ground is a rugged, undulating upland, attaining its maximum of height a little south of the Calvaire d’Illy, at a point where the Bois de la Garenne begins to clothe the steep slopes on the south and east. Lower still is a deep defile, called the Fond de Givonne, through which, turning the wood, runs the highway from Sedan to Bouillon, a town on the Semoy in Belgium. The eastern face of the position, therefore, was the line of the Givonne, a belt of cottages, gardens, factories and villages; the southern and south- western was the fortress and the Meuse; the north-western front was on the hills between Floing and Illy, and the lowlands on the loop of the Meuse. The interval between Illy and the Givonne was, at first, neglected because the French held that no troops could work through the dense forest and broken ground. The issues from this man-trap were the narrow band of territory between the head of the Meuse loop and the wooded Belgian frontier; the high road to Bouillon; the routes eastward to Carignan up the Chiers, and the gate of Torcy on the south. They were all difficult, and in the nature of defiles which can only be traversed slowly, even in time of peace, by large bodies of men, horses, guns and wagons. Within this remarkable inclosure the French Army sat down on the 31st of August. The 12th and the 1st Corps, Lebrun’s and Ducrot’s, held the line of the Givonne, looking east and south-east, because Lebrun had to guard the Meuse at Bazeilles. The 5th Corps, now under De Wimpffen, was partly in the “old camp,” close under the fortress, and partly behind the 7th, which, as we have said, occupied the rolling heights between Floing and Illy with a strong
- 55. outpost in St. Menges, at the head of the Meuse loop on the road which led to Mézières through Vrigne aux Bois—the road supposed to be unknown to the Germans, because it was not laid down on the French maps. The cavalry posted in rear of the 7th were the divisions of Margueritte, Bonnemains and Amiel, while Michel was behind Ducrot’s left at the village of Givonne. The sun set, and the night passed, yet Marshal MacMahon expressed no decision. Believing that the enemy’s numerical strength had been exaggerated, or that he could break out in any direction when he pleased, or trusting to fortune and the opportunities which might offer during the conflict, perhaps imagining that Von Moltke would grant him another day, the Marshal became the sport of circumstance which had escaped his control. “The truth is,” he said to the Parliamentary Commission, “that I did not reckon on fighting a battle on the ground we occupied. I knew already that we had no provisions, and that the place was barely supplied with munitions, but I did not yet know on which side I ought, on the morrow (the 1st) to effect my retreat.” The unfaltering adversary had no such doubts, and his firm purpose brought on not only the Battle, but the Investment of Sedan. For the information which reached the Great Head-quarters during the evening of the 31st, induced Von Moltke to quicken the operations. He inferred that no attempt would be made by the French to break out by Carignan; that they might try to reach Mézières or pass into Belgium; and as he was eager to frustrate their escape by any route, he instructed the Prussian Crown Prince to set his Corps in motion during the night. The Prince immediately issued the needful orders, and directed Von der Tann to attack with his Bavarians at dawn, without awaiting the arrival of the 12th Corps, so that Lebrun in Bazeilles being held fast, the attention of the French
- 56. might be attracted towards that side. The Saxon Prince, being duly informed, entered with characteristic spirit and daring into the plan, and not only determined to be early on the scene of action with the 12th and the Guard, but to push the latter well forward, so as to anticipate the French should they endeavour to gain the Belgian border. Thus a common motive animated the German chiefs who, in taking firm steps to gain a decisive result, were so well seconded by their tireless and intrepid soldiers. The Battle of Sedan. A thick white mist filled the valley of the Meuse on the morning of the 1st of September, 1870, so thick that Von der Tann’s Bavarians, marching towards the railway bridge and the pontoons above it, could not see many steps ahead, as in two columns they moved at four o’clock in careful silence through the dense and clammy atmosphere. At that very time General Lebrun, whose anxieties kept him awake, started up, and rushing forth, made the first bugler he encountered sound the call, which roused the wearied troops sleeping on the hills between Bazeilles and Balan. Yet it would seem that, outside the former village, no adequate watch was kept, for when the leading Bavarians emerged from the fog, they gained at once possession of several houses, and even entered the principal street without firing a shot. It was only when the enemy were within the place, that the gallant Marine Infantry, posted in the houses and behind barricades, abruptly arrested the intruders by opening a smart fire. Then began a sanguinary contest for the possession of Bazeilles, which raged during many hours; a series of street fights in which the inhabitants took an active part; combats ebbing and flowing through and round the market-place, the church, the larger
- 57. mansions, and the pretty park of Monvillers, washed and beautified by the stream of the Givonne. Without a detailed plan, the incidents of this terrible episode in the battle, are unintelligible. Vassoigne and Martin des Pallières, before the latter was wounded on the 31st, had devised a plan of resistance worthy of the gallant division they led, and it may be said that the defence of Bazeilles was the most creditable feat of arms performed by the French on that dreadful day. During the earlier hours, indeed, they kept the upper hand, driving the Bavarians out of the village on all sides, but being unable to eject them from two stone houses abutting on the chief street. The Bavarian batteries beyond the Meuse could not open fire until six o’clock, because the fog had shut out the view, which even then was indistinct. About this time General Lebrun, who was quickly on the scene, had called reinforcements from the 1st and 5th Corps; but then the Saxons had come up opposite La Moncelle, where one battery, firing at long range, astonished Lebrun, who saw that the shells from his own guns fell short, or burst in the air. When the 12th assailed La Moncelle fresh Bavarian columns had crossed the Meuse, and the fierce conflict which began in Bazeilles, had extended to the park of Monvillers, where the French fought steadily. After four hours strenuous battle, no marked progress had been made in this quarter, where three Bavarian brigades had fallen almost wholly into skirmishing order, scattered amidst the houses and lanes of the villages, and some part of the park on the left bank of the Givonne. Von der Tann bringing over another brigade and the reserve artillery from the left bank of the Meuse, called up a division of the 4th Corps which he held back as a reserve. During the course of this stubborn combat, the Saxon Corps had seized La Moncelle, and had brought ten batteries to bear on that village and Daigny, their left flank being
- 58. prolonged by two Bavarian batteries. The accuracy of their fire still further astonished General Lebrun, who confesses that he had never seen such artillery. He and his staff, six or eight persons, were on an eminence above La Moncelle. “The shells,” he writes, “cut off one branch after another, from the tree at the foot of which I stood holding my horse;” and he goes on to say that in quick succession, one officer was killed, two mortally wounded, and two men who bore his fanion were hit. He was as much impressed by the “avalanche de fer” as Marshal Canrobert himself. The infantry in Bazeilles resisted superbly, but the French General was none the less amazed by the terrible fire of the German guns. Between eight and nine the wave of battle was flowing up the Givonne, for the Guard were now approaching from Villers-Cernay. MacMahon’s Wound and its Consequences. Meanwhile, inside the French lines, the drama had deepened, for the Commander-in-Chief had been wounded. Marshal MacMahon has related how, before daybreak, fearing lest the Germans should have moved troops over the Meuse at Donchery, he had sent two officers to look into matters in that quarter, and was awaiting their return when, about five o’clock, he received a despatch from Lebrun, which made him mount his ready-saddled horse and ride towards Bazeilles. Arrived there he saw that the place was well defended, and went to the left intending to examine the whole line of the Givonne, especially as Margueritte had sent word that German troops were moving towards Francheval. Halting above La Moncelle, not far from Lebrun, the Marshal has stated that while he was gazing intently upon the heights in front of the Bois Chevalier, and could not see anything, he was struck by the fragment of a shell. At first he
- 59. thought that he was only bruised, but that being obliged to dismount from his horse, which was also wounded, he fainted for a moment, and then found that his wound was severe. Unable to bear up any longer he gave over the command of the Army to General Ducrot, and was carried to Sedan. That officer did not hear of the event until seven or later; it is impossible to fix precisely the moment when the Marshal was hit, nor when Ducrot learned his destiny, the evidence is so contradictory; but sometime between seven and eight Ducrot took the reins. His first act was to order a retreat on Mézières; Lebrun begged him to reflect and he did, but soon afterwards became positive. “There is not a moment to lose,” he cried; and it was arranged that the retreat should be made in echelons, beginning from the right of the 12th Corps. Neither General knew the real facts of the situation, nor guessed even how vast were the numbers of the enemy. The retreat began; it attracted the notice of Napoleon III., who had ridden on to the field above Balan; and it roused De Wimpffen. He carried in his pocket an order from Palikao authorizing him to succeed MacMahon, if the Marshal were killed or disabled. He had kept the fact secret; after the Marshal fell he still hesitated to use his letter, but not long. The combat about Bazeilles was well sustained; the cavalry had been out a little way beyond St. Menges and, as usual, after a perfunctory search, had “seen nothing,” the attack on the Givonne even was not fully developed. General de Wimpffen, perhaps from mixed motives, resolved to interfere and show his old comrades how a man who really knew war could extricate a French Army from perils in which it had been placed by weakness and incompetence. He certainly thought himself a great man, and he roughly stopped the retreat. Ducrot was indignant, but he obeyed.
- 60. Lebrun was not more favourably affected by De Wimpffen’s loud voice and overbearing manner. “I will not have a movement upon Mézières,” he exclaimed. “If the Army is to retreat, it shall be on Carignan and not on Mézières.” It should again be observed that the new Commander-in-Chief was quite as ignorant of the facts as his predecessors, and even when he wrote his book many months afterwards had not learned from sources open to all the world how many men stood at that moment between him and Carignan, nor was he at all acquainted with the difficult country through which he would have to move. Ducrot’s plan, which would have placed the Army between the Meuse below Sedan and the forest on the frontier, leaving a clear sweep for the guns of the fortress, was far more sensible than that of his imperious rival. Still, to have a chance of success, it should have been begun early in the morning, when the 5th and 11th German Corps were struggling towards the woods; even then it would have probably failed, but there would have been no capitulation of Sedan. General de Wimpffen, although he did not know it, was actually playing into the hand of Von Moltke, who desired above all things that the French Corps on the Givonne should remain there, because he knew, so great were his means, so firm his resolution, and so admirable as marchers and fighters were his soldiers, that the gain of a few hours would enable him to surround the Army of Chalons. How far the retreat from the front line was carried, when it was stayed, and in what degree it injured the defence, cannot possibly be gleaned from the French narratives, which are all vague and imperfect in regard to time and place. We know that the Germans did not carry Bazeilles until nearly eleven o’clock, and then only by dint of turning movements executed by the Saxons and fresh
- 61. Bavarian troops from the direction of La Moncelle. General Ducrot, in his account, places his stormy interview with De Wimpffen at a little after nine; and he says that when it ended he spurred in haste towards his divisions—Pellé’s and L’Hériller’s—and made them descend a part of the positions which they had climbed a few instants before. Lebrun is equally vague. He says in one place that when De Wimpffen came up his first brigades had “partly” crossed the Fond de Givonne, and in another, that the Marine Infantry had abandoned Bazeilles, which they had not done before nine o’clock. General de Wimpffen’s recollections are still more confused and his chronology unintelligible; so that it is impossible to ascertain precisely what happened beyond the Givonne after Ducrot ordered and his successor countermanded the retreat. If we take the German accounts, and try to measure the influence of the much- debated retreat by the resistance which the assailants encountered, we may doubt whether it had much greater influence on the issue than that which grew out of the impaired confidence of the troops in their antagonistic and jealous commanders. Nevertheless, it is probable that the swaying to and fro in the French line between Bazeilles and the village of Givonne, after nine o’clock, did, in some degree, favour the assailants, and render the acquisition of Bazeilles as well as the passage of the brook less difficult and bloody. In any case, the intervention of De Wimpffen can only be regarded as a misfortune for the gallant French Army, which can hardly find consolation in the fact that within four-and-twenty hours he was obliged to sign with his name the capitulation of Sedan. This needful explanation and comment serves to illustrate the disorder, the infirmity of purpose, and the rivalries which existed in the French camp; and we may well agree with Marshal MacMahon
- 62. when he says that the blow which obliged him to relinquish the command was a grievous event. Doubtless he would have taken a decided course had he not been wounded, and would have marched, if he could, with all his forces, either on Mézières or Carignan; and besides, he says, there was Belgium near at hand. He would not have tried to do all three at once. It is only an Army, well compacted and educated from the bottom to the top which can, without serious detriment, bear three successive commanders in three hours. Progress of the Battle on the Givonne. While the French generals, almost in the presence of the helpless Emperor, were using high words and thwarting each other’s plans, the German onset had proceeded on all sides with unabated vigour. But, about nine o’clock, or a little earlier, the French dashed forward so impetuously that the foremost German troops on the Givonne as far as Daigny, had to give ground; and the batteries were so vexed by musketry fire that they also fell back on some points. In fact Lebrun’s left and Ducrot’s right came on with great spirit, and shook, but did not arrest long the hostile line. It was not until this period that the French in Daigny pushed a brigade on to the left bank of the Givonne and occupied ground which, by the confession of their staff officers, had never been reconnoitred. They brought over a battery, and General Lartigue rode with them. The brunt of the onslaught, falling upon the Saxon infantry immediately in front, these were hard bested; but reinforcements arriving on either hand closed in upon the enemy’s flanks, and, not only was he routed from the field, but, being swiftly pursued, his battery was captured, and the Saxons following the French into Daigny wrested from them the
- 63. village, the bridge, and the opposite bank of the brook. General Lartigue’s horse was killed by a shell, and he narrowly escaped capture, and was then, or shortly afterwards, wounded. His chief of the staff, Colonel d’Andigné, hit twice, dropped in a field of beet- root. Shells from his own side fell near him, and he was grateful to them because they drove away a pig which came and sniffed at his wounds. Saxon soldiers gave him wine and lumps of sugar, but one of them stole his watch and cross; in the end he was tenderly carried to an ambulance. Some of the Zouaves engaged in this combat about Daigny, cut off from the main body of fugitives, turned northward, entered the woods, and reached Paris after traversing the Belgian border. The Germans owed their quick success at Daigny to the fact that Lartigue was not supported, and to the fortunate advent, at a critical moment, of the leading troops of the Second Saxon Division, the whole of the 12th Corps being now on the ground, engaged or in reserve. It need scarcely be remarked that the batteries, as usual, preceded the bulk of the infantry, for it was the Saxon guns which extorted the admiration of Lebrun. The attack, which had been made from his side, upon the Saxons and Bavarians about La Moncelle, was equally brilliant at the outset, for, as we have stated, the German batteries were driven back by the close musketry, and the French were advancing impetuously, when a Saxon regiment and part of a Bavarian brigade striking into the fight, stopped the French and drove them across the rivulet. Then the artillery returned; soon there were ninety-six guns in action; and the infantry pressing on, restored the battle. But in Bazeilles itself the Marines had gained ground, and fresh troops had to be poured into the village or upon its outskirts to sustain the assailants, who were still held at bay by
- 64. the stout defenders. Yet the final stroke at the village was delivered shortly after this check. The troops in Monvillers and La Moncelle simultaneously swept forward from the orchards, and osier-beds, and gardens, until they emerged on the heights beyond, and showed a front which threatened the road from Bazeilles to Balan. The French stronghold in the place was a large villa on the north, which had resisted all day; but now the freshly arrived Bavarians penetrated into the garden and turned the building on one side; while the Saxons grouped in the park of Monvillers, cutting a path through the hedges with their billhooks, appeared on the other. The French then retreated; but the splendid defence of the whole position had inflicted a heavy loss on the adversary. In Bazeilles itself a conflict continued between the armed inhabitants and the Bavarians, and soon after the whole village was in flames. Whether it was set on fire purposely or not is to this day a matter of bitter controversy; but it stands on record that only thirty- nine lay persons met their deaths, during this long contest, from fire or sword. It was not the interest of the Germans to create a furnace across a line of road; and one effect of the conflagration was that the German pioneers, unable to quench it, were compelled to open a line of communication with the troops on the fighting line outside the burning village. The French retired and reformed between the Fond de Givonne and Balan, whence their line ran northward, no longer in the valley, but along the uplands to the Calvaire d’Illy; for the Prussian Guard, issuing from Villers-Cernay and Francheval, had thrust the French out of the village of Givonne, and, long before Bazeilles was finally mastered, had established powerful lines of guns which harassed the French troops in the Bois de la Garenne. In fact, by nine o’clock,
- 65. there were six guard batteries in action, and two hours afterwards the number was increased to fourteen. Givonne was seized a little later, and infantry support afforded to the right of the 12th Corps; but Prince Augustus, in conformity with his instructions, held the main body of the Guard ready to march towards Fleigneux, effect a junction with the Third Army, and bar the road to Bouillon. From an eminence a little east of Givonne and just south of La Viré farm, whereon eighteen guns stood, the Prince, looking westward about nine o’clock, saw the smoke of that combat near St. Menges, which he knew marked the formidable intervention of the 5th and 11th Corps, whose operations in the forenoon must now be succinctly described. The March on St. Menges. It will be remembered that, on receiving a pressing order from Von Moltke, the Prussian Crown Prince directed the two Corps just named and the Würtemberg division to move out in the dark and occupy the Mézières road in order to intercept the French should they endeavour to retire upon that town. They promptly obeyed. The Würtembergers crossed the Meuse on a bridge of their own making, at Dom le Mesnil; the 5th and 11th at Donchery by the permanent bridge and two improvised passages. The object of the two Corps was to occupy the nearest villages on the Mézières road, Vrigne aux Bois and Vivier au Court, both which were attained about half-past seven, when the contest was fierce on the Givonne. Here the generals commanding, Von Kirchbach and Von Gersdorf, received that despatch from the Prussian Crown Prince which directed them to march on St. Menges and Fleigneux, for at head-quarters a strong hope had now arisen that the Army of Chalons could be surrounded.
- 66. The 11th moved on the right, next the Meuse, the 5th on the left; but the roads were few between the river and the forest—one column lost its way, and both Corps at the head of the Loop had to use the same road. No French scouts were out along this important line of communication. Margueritte’s horsemen had patrolled a short distance, about six, but neither saw nor heard of the approaching columns; nor until the German Hussars, leading the erring column ascending the Meuse from Montimont, had got close to St. Menges, were they discovered by a French patrol sent out at the suggestion of De Wimpffen. The 11th and 5th Corps engage. The shots exchanged by the hostile cavaliers aroused the French infantry in St. Menges; but they offered no resistance when the nearest German battalion attacked the village, which was immediately occupied. Two companies, prolonging the movement, effected a lodgment in Floing and could not be expelled; while three batteries, escorted by the Hussars, dashed upon the ridge south of St. Menges, partly protected by a copse, and opened fire on the French. It was this initial combat which attracted the notice of Prince Augustus of Würtemberg, who looked with interest, from his hill above the Givonne, upon the white battle smoke which curled up beyond the heights of Illy. Shortly afterwards seven additional batteries issued from the defile and formed in succession on the hill —the same which had filled General Douay with anxiety the day before—and some infantry battalions followed; but the body of the 11th Corps was only just clearing the pass, and the 5th was still behind. In order to protect the batteries, infantry supports were advanced on either flank and in front towards the Illy brook. General
- 67. Margueritte, on the Calvaire d’Illy had watched this unwelcomed development of artillery. Seeing the infantry spread out below, he thought that his horse might ride them down and then disable the line of batteries, which seemed to be without adequate support. Accordingly, by his order, General de Galliffet led forth three regiments of Chasseurs d’Afrique and two squadrons of Lancers against the intrusive foot and audacious gunners. But he never got near the batteries. Swooping down the slope upon the infantry below him, his men and horses soon fell fast, and although they swept through the skirmishers, they were crushed by the fire of the supports and the guns on the hill and the squads of infantry on either side. They endeavoured to ride in upon the flanks, but their bravery was displayed in vain, for nothing could live under the fire which smote them, and they rode back, frustrated, to the shelter of their own lines. The cavalry outburst had been repelled by a few companies of foot on an open hill-side. So puissant is the breech- loader in the hands of cool infantry soldiers. But the French foot took up the game, and the chassepot, deftly plied, forced the forward German skirmishers to fall back on the villages and hills. Gradually the two Corps arrived on the scene. Before eleven o’clock the artillery of the 5th, preceding its infantry, went into line on a second ridge to the westward, and soon twenty-four batteries— that is, 144 guns—were pouring an “avalanche de fer” into the French position, and crossing their fire with that of the Guard batteries, which showered their shells into the right rear of Douay’s men from the heights beyond the Givonne. About this time, also, as reinforcements came up to Fleigneux, the companies there moved westward towards Olly; captured, on their way, eight guns, many horses, much munition, and above a hundred officers and men, who
- 68. seemed intent on escaping over the frontier, and finally entered Olly, where soon afterwards they were gratified by the arrival of a squadron of Prussian Hussars of the Guard. Thus was the circle completed which placed the two Armies in communication. In front of the right wing the two companies which at the outset obtained a lodgment in Floing, were at length supported and relieved. As the infantry from the wooded region north of the Meuse Loop arrived, they took the place of the battalions near the guns, and these then went forward upon Floing, one after the other, and by degrees got possession of the village. But the French delivered a counterstroke so well pushed that the defenders of Floing could not keep them back, and they were only thrust out by the timely intervention of three fresh battalions from St. Menges. The French retired towards the heights of Cazal, and for some time stopped the further advance of their foes. The battle was now practically won; for the Germans held Balan as well as Bazeilles, supported by one-half the 2nd Bavarian Corps brought up to aid the 1st; one division of the 4th Corps was deep in the fight, and the other in reserve, close at hand; the line of the Givonne, from end to end, was occupied on both banks; the Guard Cavalry, after vainly trying to charge up the Calvaire d’Illy, were behind the 5th Corps; south of the Meuse a Bavarian division faced the fortress; and to the west the Würtembergers interposed between Vinoy’s troops in Mézières and Sedan. Above all, a little after one o’clock, there were no fewer than 426 guns hailing shells upon the unfortunate French, who were almost piled one upon another in an area which did not measure two miles either in depth or breadth. It stands on record that there were in full action twenty- six batteries on the North, twenty-four on the East, ten to the West
- 69. of La Moncelle, and eleven on the South between Wadelincourt and Villette—an array of force enough to crush out all resistance; but the conflict still continued, for no one had authority sufficient to stop the awful carnage. The Condition of the French Army. The main interest of the drama henceforth centres in the despairing efforts of the French to avert the catastrophe of Sedan. Early in the morning the Emperor Napoleon mounted his horse and rode out with his own staff to witness the battle. On his way towards Bazeilles he met and spoke to the wounded Marshal, who was being carried to the hospital in Sedan. Then the Emperor rode towards the hills above La Moncelle, and for several hours he lingered on the field, well under fire, for two officers were wounded near him; but he had no influence whatever on the battle. Soon after taking command, De Wimpffen, riding out of the Fond de Givonne, came plump upon Napoleon as he watched the fight near Balan. “All goes well, Sire,” said the General; “we are gaining ground;” and when His Majesty remarked that the left, meaning the front towards St. Menges, was threatened, the General replied, “We shall first pitch the Bavarians into the Meuse, and then, with all our forces, fall upon the new foe.” They parted, the Emperor returning to Sedan, whence he did not emerge again that day, and the General careering towards the fight. Then followed a sharp dispute between De Wimpffen and Ducrot, in the presence of Lebrun, ending in the order to stop the so-called retreat which had scarcely begun. It is impossible to reconcile the conflicting accounts of these officers; but De Wimpffen’s own words show that, at the time, he did not attach great importance to the attack on Douay, for to that General he
- 70. wrote, “I believe in a demonstration upon your Corps, especially designed to hinder you from sending help to the 1st and 12th Corps,” and he asked him to aid Lebrun. Then he went himself to the position held by Douay, in order to expedite the despatch of reinforcements. “Come and see for yourself,” said Douay, on reaching the heights. “I saw quite a hostile Army extending afar,” writes De Wimpffen, “and a formidable artillery—the big batteries of the 5th and 11th Corps—firing with a precision which, under other circumstances,” he adds, “I should have been the first to admire.” Prince Bibesco says that De Wimpffen promised to send troops from the 1st Corps to occupy the Calvaire d’Illy, and then went away. As he was riding back, in that state of emotion which the French describe by the phrase, “le cœur navré,” he encountered Ducrot. “The events which I predicted,” said the latter, “have happened sooner than I expected. The enemy is attacking the Calvaire d’Illy. Douay is greatly shaken. Moments are precious. Hurry up reinforcements if you would keep that position.” “Well,” retorted De Wimpffen, still believing that he had only Bavarians to deal with, “look after that yourself. Collect what troops you can and hold the ground while I attend to the 12th Corps.” Thereupon Ducrot ordered up guns and infantry; while then, or shortly afterwards, De Wimpffen called for troops from Douay, who, believing the Calvaire was or would be occupied by Ducrot’s people, sent off three brigades, and put his last division in front line. Apparently the cross currents of wandering battalions met in the wood of Garenne; and it is not easy to see how any advantages were obtained by the shifting to and fro which went on. Ducrot was anxious to defend the Illy plateau; De Wimpffen desired to break out towards Carignan. He fondled the idea at one o’clock, when neither object could possibly
- 71. be attained; but if there had been a chance left, the conflict between the two Generals would have sufficed to destroy it. That “Army” which De Wimpffen saw from the north-western heights came on in irresistible waves. The French infantry could not endure the thick and ceaseless hail of shells from the terrible batteries. The French artillery, brave and devoted, vainly went into action, for the converging fire from the hostile hills blew up the tumbrils, sometimes two at once, killed and wounded the gunners, and swept away the horses. Ducrot’s reinforcements, despite his forward bearing and animated language, melted away into the woods, and the last battalions and the last two batteries led up by Douay were speedily forced to retire. The Germans, already in the village of Illy, advanced to the Calvaire, while the troops of the 11th Corps sallied out of Floing, deployed on both sides, and soon the interval between the two villages was full of hostile troops. General Ducrot pictures himself, and doubtless truly, as using every effort by word and example to rally and hold fast the foot; but they could not be held; they slipped off and vanished under the trees. At this time the only strong body of French was Liébert’s division above the terraced hill which leads up to Cazal, and the cavalry of Margueritte and Bonnemains lurking in the hollows and under the cover of trees. To these men Ducrot appealed, and his appeal was nobly answered. The French Cavalry Charge. General Margueritte commanded five regiments of horse, principally Chasseurs d’Afrique. At the request of Ducrot he promptly moved out from cover, and prepared to charge; but wishing to reconnoitre the ground, he rode in advance, and was hit in the head by a bullet which traversed his face. Mortally wounded, he gave the
- 72. command to De Galliffet, and rode off, supported by two men, and grasping the saddle with both hands, “the star of his arm,” as Colonel Bonie poetically calls him. Then De Galliffet performed his task, and rode straight into the intrusive enemy. For half an hour, on the hill sides south of Floing, and even the lowlands bordering the Meuse, the dashing French horsemen dauntlessly struck at their foes. The German infantry scattered in lines of skirmishers, were just attaining the crest of the eminence, when the cavalry dashed upon them. They broke through the skirmishers, but fell in heaps under the fire of the compact bodies of supports. Failing to crush a front, they essayed the flanks and even the rear, and nothing dismayed, sought again and again to ride over the stubborn adversary, who, relying on his rifle, would not budge. The more distant infantry and the guns, when occasion served, smote these devoted cavaliers. Sometimes the Germans met them in line, at others they formed groups, or squares as the French call them, and occasionally they fought back to back. One body of horse rode into a battery, and was only repelled by the fire of a company of infantry. Another dashed through a village on the banks of the river, and although they were harried by infantry, and turned aside and followed by some Prussian hussars, several rode far down the river, and created some disorder in the German trains. There were many charges, all driven home as far at least as the infantry fire would permit, more than one carrying the furious riders up to the outskirts of Floing. But, in the end, the unequal contests everywhere had the same result—bloody defeat for the horseman, who matched himself, his lance or sword and steed against the breech-loader held by steady hands in front of keen eyes. Yet it is not surprising that these daring charges excited the ungrudging admiration and deep sympathy of friend and foe. They
- 73. did not arrest the march of the German infantry, or turn the tide of battle, or even infuse new courage into the French soldiers, who were exposed to trials which few, if any, troops could bear. But they showed, plainly enough, that the “furia francese” survived in the cavalry of France, and that, if the mounted men refused or disdained to perform more useful work by scouting afar and covering the front of armies, they could still charge with unabated heroism on the field of battle. They were dispersed, and they left behind heaps of dead and dying—one-half their strength resting on the scene of their daring. Three Generals, Margueritte, Girard and Tilliard, were killed, and Salignac-Fenelon was wounded. The Germans say that their own losses were small, but that among the Jägers a comparatively large number of men were wounded by the sword. These notable exploits were done about two o’clock or a little later; and, with slight exceptions, they mark the end of desperately offensive resistance on the part of the French. During the next hour the Germans pressed their adversaries close up to Sedan. “When the cavalry had been driven back in disorder,” says Ducrot in his sweeping style, “the last bodies of infantry which had stood firm broke and fled. Then on the right and left, with loud hurrahs, which mingled with the roar of cannon and musketry, the Prussian lines advanced.” The statement is too superlative. The cavalry in squads, wandered, no doubt, from ravine to ravine, seeking an asylum, or tried to enter the fortress. The remains of several brigades were piled up in the wood of Garenne, and exposed to an incessant shell fire. But Liébert’s division stoutly defended Cazal, and gave back, foot by foot, until they also were under the ramparts. Towards four o’clock the converging German columns, despite frantic onsets from bands of French infantry,
- 74. especially on the Givonne front, had thrust these over the deep hollow way, and the victors were only halted when they came within range of the garrison guns. General de Wimpffen’s Counterstroke. Throughout the battle General de Wimpffen cherished the idea that it would be feasible to crush “the Bavarians” and retreat on Carignan. At one o’clock he sent a despatch to General Douay, telling the General to cover his retreat in that direction. Douay received it an hour afterwards, and he then replied that “with only three brigades, without artillery, and almost without munitions,” the utmost he could do would be to retreat in order from the field. That was near the moment when Liébert began to fall back, fighting stiffly, from Cazal. At a quarter past one De Wimpffen wrote a letter to the Emperor saying that “rather than be made prisoner in Sedan,” he would force the line in his front. “Let your Majesty,” he said, “place himself in the midst of his troops; they will hold themselves bound in honour to fray out a passage.” His Majesty took no notice of this appeal, and De Wimpffen waited in vain for a reply; but he spent the time in an endeavour to dash in the barrier in his front, direct an attack on the Givonne, which failed; and to organize an onset on Balan, which partly succeeded. He went into Sedan and brought out troops, and gathered up all he could from the errant fragments of a broken Army. With these he fell fiercely and unexpectedly upon the Bavarians in Balan; refused to suspend the fight when ordered by the Emperor to open negotiations with the enemy; and by degrees became master of all the village except one house. But he could not emerge and continue his onslaught, for the hostile artillery began to play on the village; reinforcements were
- 75. brought up, arrangements were made to frustrate the ulterior aim of the French and recover the lost ground. Against a resolute advance the infantry led by De Wimpffen could not stand, and possession of the village was regained just as the white flag went up over the nearest gate of Sedan. Suddenly the firing ceased on both sides. Although respectfully described by the Germans, General de Wimpffen’s last charge is scoffed at by Ducrot and Lebrun, whom he had enraged by declaring both guilty of disobedience. Lebrun, who was an eye-witness as well as a gallant actor in the forlorn hope, says that they had not gone a quarter of a mile before the column broke and took refuge in the nearest houses. Looking back, De Wimpffen is reported by his comrade to have said, “I see we are not followed and that there is nothing more to do. Order the troops to retreat on Sedan.” The battle had, at length, come to an end. The German infantry, both near Cazal and Balan were within a short distance of the fortifications; in the centre they stood south of the Warren Wood; to the eastward long lines of guns crowned the heights on both banks of the Givonne; on the south, the gate of Torcy was beset, and behind all the foremost lines were ample reserves, horse as well as foot, which had never fired a shot. The number of batteries had increased during the afternoon, for the Würtemberg artillery was called over the Meuse and set in array at the bend of the river above Donchery. Even the high-tempered, if imperious, De Wimpffen was obliged to admit that through this dread circle, neither for him nor any other, was there an outlet. The agony had been prolonged, but enough had been done to satisfy the “honour” of the most obstinate and punctilious of generals. The wearied, wasted, famished, and unnerved French troops were thankful for the impressive stillness and unwonted rest which came
- 76. abruptly with the declining sun, even though it set the seal on a horrible disaster. The Emperor and his Generals. Had Napoleon III. retained that Imperial authority which he had been supposed to possess, the slaughter might have been stayed some hours before. For early in the afternoon he became convinced that the Army could not be extricated, and that the time had come when it would be well to treat. His experiences, as a superfluous attendant on the battle-field, were dolorous. The first object which met his gaze was the wounded Marshal. The depressing incident may have called up visions of Italian triumphs; and, reflecting on the painful contrast, he may have remembered what he said after returning from the sanguinary victory of Solferino—that no more would he willingly lead great Armies to war; for the sight of its horrors had touched the chord of sympathy with human suffering which had always readily vibrated in his heart. During several hours he watched the tempest lower and break in fury; he saw and felt its effects, for two officers were shot at his side; wherever he looked the clouds of encircling battle smoke rose in the clear sunshine; and when he rode back into Sedan the terrible shells were bursting in the ditches, and even on the bridge which he traversed to gain his quarters. As the day wore on his gloomy meditations took a more definite shape; he wished to stop the conflict, and he seems to have thought first that an armistice might be obtained, and then that the King of Prussia, if personally besought, would grant the Army easy terms; for the idea of a capitulation had grown up and hardened in his mind.
- 77. At his instigation, no officer has come forward to claim the honour, some one hoisted a white flag. As soon as he heard of it, General Faure, Marshal MacMahon’s Chief of the Staff, ascended the citadel and cut down a signal so irritating to his feelings; but no one told the Emperor that his solitary, independent, and Imperial action, since he joined the Army of Chalons as a fugitive, had been thus irreverently contemned. “Why does this useless struggle still go on?” he said to General Lebrun, who entered his presence some time before three o’clock. “Too much blood has been shed. An hour ago I directed the white flag to be hoisted in order to demand an armistice.” The General politely explained that other forms were necessary—the Commander-in-Chief must sign a letter and send a proper officer, a trumpeter, and a man bearing a white flag, to the chief of the enemy. Lebrun drew out such a form, and started forth. Faure, who had just pulled down the white flag, would not look at it; De Wimpffen, seeing Lebrun ride up followed by a horseman who carried a rag on a pole, shouted out, “I will not have a capitulation; drop that flag; I shall go on fighting;” and then ensued their adventures about Balan, which have been described. When Lebrun had gone, Ducrot, and subsequently Douay, visited the Emperor. Ducrot found the interior of the fortress in a state which he qualifies as “indescribable.” “The streets, the squares, the gates were choked up with carts, carriages, guns, the impedimenta and debris of a routed Army. Bands of soldiers, without arms or knapsacks, streamed in every moment, and hurried into the houses and churches. At the gates many were trodden to death.” Those who preserved some remains of vigour exhaled their wrath in curses, and shouted “We have been betrayed, sold by traitors and cowards.” The Emperor still wondered why the action went on, and rejected
- 78. Ducrot’s suggestion of a sortie at night as futile. He wished to stop the slaughter; but he could not prevail on Ducrot to sign any letter. Douay at first appeared disposed to accept the burden, but De Failly or Lebrun induced him to revoke his consent by remarking that it entailed the duty of fixing his name to a capitulation. General de Wimpffen sent in his resignation, which, as the Emperor could not induce one of the other generals to take his place, was absolutely refused. The shells were bursting in the garden of the Sub- Prefecture, in the hospitals, the streets, and among the houses, some of which were set on fire. In these dire straits the Emperor at length resolved that the white flag should be again unfurled, and should, this time, remain aloft in the sunshine. Meantime, as evident signs indicating a desire to negotiate had appeared at various points, and as the white flag surmounted the citadel, the King directed Colonel Bronsart von Schellendorf and Captain von Winterfeld to summon the place to capitulate. When Bronsart intimated to the Commandant of Torcy that he bore a summons to the Commander- in-Chief, he was conducted to the Sub-Prefecture, “where,” says the official narrative, “he found himself face to face with the Emperor Napoleon, whose presence in Sedan until that moment had been unknown at the German head-quarters.” The arrival of the Prussian officer seems to have occurred just as the Emperor finished writing a letter to the King destined to become famous. But he answered Bronsart’s request that an officer fully empowered to treat should be sent to the German head-quarters, by remarking that General de Wimpffen commanded the Army. Thereupon, Colonel Bronsart departed, bearing a weighty piece of intelligence indeed, but no effective reply; and soon afterwards General Reille, intrusted with
- 79. the Imperial letter, rode out of the gate of Torcy and ascended the hill whence the King had witnessed the battle. King William and his Warriors. An eminence, selected by the Staff because it commanded an extensive view, rises a little south of Frenois—the site has been marked on the map with a small pyramid—and upon this, about seven o’clock, just as the fog was lifting, King William took his stand. When the mists vanished, the sun poured his dazzling splendour over the landscape, and the air was so lucid that everything could be seen distinctly through a powerful field-glass. “The sun shone out in full power,” says Prince Bibesco. “The sun was exceedingly powerful,” writes Dr. Russell. “The day had become so clear”—he is writing of the same period as the Prince—“that through a good glass the movements of individual men were plainly discernible.” And, a little earlier, he says, “on the hills, through wood and garden,” he was looking towards the Givonne, “and in the valleys, bayonets glistened, and arms twinkled and flashed like a streamlet in moonlight.” And so it continued to the end. “The hills of the battlefield,” writes Dr. Moritz Busch, “the gorge in its midst, the villages, the houses and the towers of the fortress, the suburb of Torcy, the ruined [railway] bridge to the left in the distance, shone bright in the evening glow, and their details became clearer every minute, as if one were looking through stronger and stronger spectacles.” Through such a rich and transparent atmosphere the King gazed from his height upon the city wherein Turenne was born, in September, 1611, and on the battle which has made the little town on the Meuse, which Vauban fortified, still more memorable. A glimpse of the group on the hill is fortunately afforded by Dr. Russell, whose keen eyes on a battlefield
- 80. seem to overlook nothing. “Of the King, who was dressed in his ordinary uniform, tightly buttoned and strapped,” it is noted that he “spoke but little, pulled his moustache frequently, and addressed a word to Von Moltke, Roon, or Podbielski,” who looked frequently through a large telescope mounted on a tripod. “Moltke,” he goes on, and the touch is characteristic, “when not looking through the glass or at the map, stood in a curious musing attitude, with his right hand to the side of his face, the elbow resting on the left hand crossed towards his hip.” A picture of Von Moltke, which, taken with what another observer calls his “refined and wrinkled face,” deserves to live in the memory. Count Bismarck, we are told, “in his white cuirassier flat cap with the yellow band and uniform, stood rather apart, smoking a good deal, and chatting occasionally with a short, thick-set, soldierly-looking man in the undress uniform of a United States’ Lieutenant-General.” It was Sheridan. And near these were many less famous personages, but representative of “all Germany,” as one writer puts it. On another hill a little further west, whither Dr. Russell transferred himself, was a second and notable group, which he sketches. “The Crown Prince with his arms folded, and his flat cap, uniform frock, and jack boots; Blumenthal so spruce and trim; half-a-dozen princes and many aides-de-camp” were all sharply and well-defined on the sky-line. Thus these two groups, “from morn to dewy eve,” looked down, on, and into a scene which nature and man had combined to make at once beautiful and sublime. It was towards the King’s hill that General Reille turned when he rode out of the Torcy gate. Walking his horse up the steep, he dismounted, and taking off his cap, presented a letter to his Majesty. King William, breaking the Imperial seal, read these phrases, which, if somewhat dramatic, are striking in their brevity:—[1]
- 81. Monsieur mon Frère, N’ayant pu mourir au milieu de mes troupes, il ne me reste qu’ à remettre mon epée entre les mains de Votre Majesté. Je suis de Votre Majesté, le bon Frère, NAPOLÉON. Sédan, le 1er Septembre, 1870. Only one half hour earlier had Colonel Bronsart brought the startling information that the Emperor was in Sedan! The King conferred with his son, who had been hastily summoned, and with others of his trusty servants, all deeply moved by complex emotions at the grandeur of their victory. What should be done? The Emperor spoke for himself only, and his surrender would not settle the great issue. It was necessary to obtain something definite, and the result of a short conference was that Count Hatzfeldt, instructed by the Chancellor, retired to draft a reply. “After some minutes he brought it,” writes Dr. Busch, “and the King wrote it out, sitting on one chair, while the seat of a second was held up by Major von Alten, who knelt on one knee and supported the chair on the other.” The King’s letter, brief and business-like, began and ended with the customary royal forms, and ran as follows: “Regretting the circumstances in which we meet, I accept your Majesty’s sword, and beg that you will be good enough to name an officer furnished with full powers to treat for the capitulation of the Army which has fought so bravely under your orders. On my side I have designated General von Moltke for that purpose.” General Reille returned to his master, and as he rode down the hill the astounding purport of his visit flew from lip to lip through the exulting Army which now hoped that, after this colossal success, the
- 82. days of ceaseless marching and fighting would soon end. As a contrast to this natural outburst of joy and hope we may note the provident Moltke, who was always resolved to “mak siker.” His general order, issued at once, suspending hostilities during the night, declared that they would begin again in the morning should the negotiations produce no result. In that case, he said, the signal for battle would be the reopening of fire by the batteries on the heights east of Frénois. The return of peace, so fervently desired by the Army, was still far off in the distance when the tired victors bivouacked in quiet, and dreamed of home through the short summer night. [1] “Not having been able to die in the midst of my troops, nothing remains for me but to place my sword in the hands of your Majesty.” How the Generals Rated each other. While General Reille, who performed his part with so much modesty and dignity, rode back over the Meuse, the Emperor still awaited, in the Sub-Prefecture, the advent of General de Wimpffen, who was fretting and fuming at the Golden Cross within the walls. According to his own confession he had become convinced that the refusal of his sovereign to head a sally from Balan had delivered over the Army to the mercy of the Germans, and violent despair had taken possession of his soul. For had not the Comte de Palikao sent him to overbear Napoleon III. and the set who surrounded him, and had he not failed to bend the monarch to his will? Twice, he repeats, with pride, “I obstinately refused to obey” the Emperor’s invitation to treat with the enemy; and because Napoleon III. had authoritatively interfered with his command he sent in that letter of resignation
- 83. which the Emperor refused to accept. At first he seemed inclined to resist as well as resent the conduct of his master, who had presumed to consult others and, by hoisting the white flag, to take, as the General haughtily says, “a decision contrary to my will.” Let the Emperor sign the capitulation. Such were the first thoughts of a man whose temper was imperious, but whose better nature was not insensible to reason. He quelled his wrath and threw off his despair, moved, as he says, by the feeling that in defending the interests of the Army he would be rendering a last service to his brave companions in arms, and to his country. So he went from the Golden Cross to the Sub-Prefecture. Still angry, he loudly asserted as soon as he entered the room that he had been vanquished in battle because, addressing the Emperor, “your Generals refused to obey me.” Thereupon Ducrot started up, exclaiming, “Do you mean me? Your orders were only too well obeyed, and your mad presumption has brought on this frightful disaster.” “If I am incapable,” retorted De Wimpffen, “all the more reason why I should not retain the command.” “You took it this morning,” shouted Ducrot, also a violent man, “when you thought it would bring honour and profit. You cannot lay it down now. You alone must bear (endosser) the shame of the capitulation.” “Le General Ducrot était très exalté,” he says in his narrative, and he calls on his brother officers who were present to testify that he used these brave words, which, in substance, appear in De Wimpffen’s account; but the latter adds that he threw back the accusation, saying, “I took the command to evade a defeat which your movement would have precipitated;” and that he requested General Ducrot to leave the room, as he had not come to confer with him! What the quiet and well-mannered Emperor thought of his two fiery and blustering Generals is nowhere stated.
- 84. The calm language in the pamphlet attributed to Napoleon III., which shows, nevertheless, how deeply he was vexed by De Wimpffen’s selfish wish to shirk his responsibilities at such a moment, takes no note of the quarrel, and simply tells us how “the General understood that, having commanded during the battle, his duty obliged him not to desert his post in circumstances so critical.” Thus, when General Reille returned with King William’s letter, he found De Wimpffen in a reasonable frame of mind and ready to perform, with courage and address, the hard task of obtaining the best terms he could for the French Army from the placidly stern Von Moltke, in whose heart there were no soft places when business had to be done. The Generals Meet at Donchery. Late on the evening of September 1st a momentous session was held in Donchery, the little town which commands a bridge over the Meuse below Sedan. On one side of a square table covered with red baize sat General von Moltke, having on his right hand the Quartermaster-General von Podbielski, according to one account, and Von Blumenthal according to another, and behind them several officers, while Count von Nostitz stood near the hearth to take notes. Opposite to Von Moltke sat De Wimpffen alone; while in rear, “almost in the shade,” were General Faure, Count Castelnau, and other Frenchmen, among whom was a Cuirassier Captain d’Orcet, who had observant eyes and a retentive memory. Then there ensued a brief silence, for Von Moltke looked straight before him and said nothing, while De Wimpffen, oppressed by the number present, hesitated to engage in a debate “with the two men admitted to be the most capable of our age, each in his kind.” But he soon plucked
- 85. up courage, and frankly accepted the conditions of the combat. What terms, he asked, would the King of Prussia grant to a valiant Army which, could he have had his will, would have continued to fight? “They are very simple,” answered Von Moltke. “The entire Army, with arms and baggage, must surrender as prisoners of war.” “Very hard,” replied the Frenchman. “We merit better treatment. Could you not be satisfied with the fortress and the artillery, and allow the Army to retire with arms, flags and baggage, on condition of serving no more against Germany during the war?” No. “Moltke,” said Bismarck recounting the interview, “coldly persisted in his demand,” or as the attentive D’Orcet puts it, “Von Moltke was pitiless.” Then De Wimpffen tried to soften his grim adversary by painting his own position. He had just come from the depths of the African desert; he had an irreproachable military reputation; he had taken command in the midst of a battle, and found himself obliged to set his name to a disastrous capitulation. “Can you not,” he said, “sympathize with an officer in such a plight, and soften, for me, the bitterness of my situation by granting more honourable conditions?” He painted in moving terms his own sad case, and described what he might have done; but seeing that his personal pleadings were unheeded, he took a tone of defiance, less likely to prevail. “If you will not give better terms,” he went on, “I shall appeal to the honour of the Army, and break out, or, at least, defend Sedan.” Then the German General struck in with emphasis, “I regret that I cannot do what you ask,” he said; “but as to making a sortie, that is just as impossible as the defence of Sedan. You have some excellent troops, but the greater part of your infantry is demoralized. To-day, during the battle, we captured more than twenty thousand unwounded prisoners. You have only eighty thousand men left. My troops and
- 86. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookultra.com