AFDX(ARINC664)协议讲解
GE Fanuc
Embedded Systems
AFDX/ARINC 664 Protocol
Tutorial
Table of Contents
Chapter 1 Overview 4 The Antecedents 4 What is AFDX? 4 Other Avionics Buses5 ARINC 429 5 MIL-STD-1553 5 Ethernet 6 ALOHA Net 6 The ALOHA Protocol 6 Ethernet Local Area Networks (Broadcast Media) 6 The Ethernet Protocol 6 Ethernet Using Category 5 UTP Copper Twisted Pairs6 Ethernet Frame Format 6 Chapter 2 Ethernet6 Full-duplex, Switched Ethernet7 Doing Away with Contention 7 Reducing Wire Runs and Weight 8 Chapter 3 End Systems and Avionics Subsystems 9 End Systems and Avionics Subsystems 9 Chapter 4 AFDX Communications Ports10 AFDX Communications Ports 10 Chapter 5 Virtual Links: Packet Routing in AFDX11 Virtual Links11 Chapter 6 Message Flows12 Message Flows12 Chapter 7 Redundancy Management13 Redundancy Management 13 Chapter 8 Virtual Link Isolation14 Virtual Link Isolation 14 Choosing the BAG and Lmax for a Virtual Link 15 Chapter 9 Virtual Link Scheduling15 Virtual Link Scheduling 15 Chapter 10 Jitter16 Jitter 16 Chapter 11 AFDX Message Structures17 Introduction 17 Implicit Message Structures 17 ARINC 429 Labels 18 Chapter 12 The AFDX Protocol Stack19 The AFDX Protocol Stack 19 Transmission 19 Reception20 Appendix A AFDX Frame Addressing and Header Structures21 Ethernet Addressing 21 IP Header Format and Addressing 21 UDP Header Format 22 Appendix B Referenced Documents23 Reference List 23
List of Figures
Figure 1 AFDX Network 4 Figure 2 ARINC 429 Communication Protocol 5 Figure 3 MIL-STD-1553 Bus Communication Protocol 5 Figure 4 ALOHA Net 6 Figure 5 Ethernet Local Area Networks (Broadcast Media) 6 Figure 6 Ethernet Frame Format 6 Figure 7 Full-Duplex, Switched Ethernet Example 7 Figure 8 AFDX versus ARINC 429 architecture 8 Figure 9 End Systems and Avionics Subsystems Example9 Figure 10 Sampling Port at Receiver 10 Figure 11 Queuing Port at Receiver 10 Figure 12 Format of Ethernet Destination Address in AFDX Network 11 Figure 13 Packet Routing Example 11 Figure 14 Message Sent to Port 1 by the Avionics Subsystem12 Figure 15 Ethernet Frame with IP and UDP Headers and Payloads 12 Figure 16 A and B Networks 13 Figure 17 AFDX Frame and Sequence Number 13 Figure 18 Receive Processing of Ethernet Frames 13 Figure 19 Three Virtual Links Carried by a Physical Link 14 Figure 20 Virtual Link Scheduling 15 Figure 21 Virtual Link Scheduling 15 Figure 22 Role of Virtual Link Regulation16 Figure 23 Two Message Structures 17 Figure 24 ARINC 664 Message Structures 18 Figure 25 AFDX Tx Protocol Stack 19 Figure 26 AFDX Rx Protocol Stack 20 Figure 27 Ethernet Source Address Format 21 Figure 28 IP Header Format 21 Figure 29 IP Unicast Address Format 21 Figure 30 IP Multicast Address Format 21 Figure 31 UDP Header Format 22
4
One of the reasons that AFDX is such an attractive tech-nology is that it is based upon Ethernet, a mature technol-ogy that has been continually enhanced, ever since its inception in 1972 In fact, the commercial investment and advancements in Ethernet have been huge compared say, to ARINC 429, MIL-STD-1553, and other specialized data-communications technologies
As shown in Figure 1, an AFDX system comprises the follow-ing components:
Avionics Subsystem: The traditional Avionics Subsystems on board an aircraft, such as the flight control com-puter, global positioning system, tire pressure monitoring system, etc An Avionics Computer System provides a computational environment for the Avionics Subsystems Each Avionics Computer System contains an embedded End System that connects the Avionics Subsystems to an AFDX Interconnect
AFDX End System (End System): Provides an “interface”
between the Avionics Subsystems and the AFDX Intercon-nect Each Avionics Subsystem the End System interface
to guarantee a secure and reliable data interchange with
other Avionics Subsystems This interface exports an ap-plication program interface (API) to the various Avionics
Subsystems, enabling them to communicate with each
other through a simple message interface
AFDX Interconnect: A full-duplex, switched Ethernet in-terconnect It generally consists of a network of switches that forward Ethernet frames to their appropriate destina-tions This switched Ethernet technology is a departure from the traditional ARINC 429 unidirectional, point-to-point technology and the MIL-STD-1553 bus technology
Chapter 1 Overview
The Antecedents
Moving information between avionics subsystems on board an aircraft has never been more crucial, and it is here that electronic data transfer is playing a greater role than ever before Since its entry into commercial airplane service on the Airbus A320 in 1988, the all-electronic fly-by-wire system has gained such popularity that it is becoming the only control system used on new airliners
But there are a host of other systems — inertial platforms, communication systems, and the like — on aircraft, that
demand high-reliability, high-speed communications, as well Control systems and avionics in particular, rely on having complete and up-to-date data delivered from source to re-ceiver in a timely fashion For safety-critical systems, reliable real-time communications links are essential
That is where AFDX comes in Initiated by Airbus in the evolu-tion of its A380 Aircraft, they coined the term, AFDX, for Avion-ics Full-DupleX, switched Ethernet AFDX brings a number of
improvements such as higher-speed data transfer — and with
regard to the host airframe — significantly less wiring, thereby
reducing wire runs and the attendant weight
What is AFDX?
Avionics Full DupleX Switched Ethernet (AFDX) is a standard
that defines the electrical and protocol specifications (IEEE
802 3 and ARINC 664, Part 7) for the exchange of data be-tween Avionics Subsystems One thousand times faster than
its predecessor, ARINC 429, it builds upon the original AFDX
concepts introduced by Airbus
Figure 1. AFDX Network
Internet
5
As shown in the example in Figure 1, two of the End Systems provide communication interfaces for three avionics sub-systems and the third End System supplies an interface for a Gateway application It, in turn, provides a communications path between the Avionics Subsystems and the external IP network and, typically, is used for data loading and logging The following sections provide an overview of the AFDX ar-chitecture and protocol But first we briefly review two of the traditional avionics communications protocols
Other Avionics Buses
This section compares AFDX to two earlier Avionics data com-munication protocols: ARINC 429 and MIL-STD-1553 ARINC 429
Receiver Receiver
Receiver Receiver
Source
Bit rates are either 100 Kbps or 12 5 Kbps
32-bit messages
Figure 2. ARINC 429 Communication Protoco l
ARINC 429 implements a single-source, multi-drop bus with up to 20 receivers (see Figure 2) Messages consist of 32-bit words with a format that includes five primary fields The Label field determines the interpretation of the fields in the re-mainder of the word, including the method of translation The point to multi-point property of ARINC 429 requires the Avion-ics system to include an ARINC 429 bus for each pair-wise communication Refer to the GE Fanuc Embedded Systems ARINC Tutorial for more details
MIL-STD-1553
Bit-rate 1 Mbps
20-bit data word
Figure 3. MIL-STD-1553 Bus Communication Protocol
MIL-STD-1553 (see Figure 3) implements a bus architecture in which all the devices attached to the bus are capable of receiving and transmitting data The Avionics subsystems at-tach to the bus through an interface called a remote terminal (RT) The Tx and Rx activity of the bus is managed by a bus controller, that acts to ensure that no two devices ever trans-mit simultaneously on the bus The communication is half duplex and asynchronous For more information, refer to the GE Fanuc Embedded Systems “MIL-STD-1553 Tutorial”
MIL-STD 1553 DATA BUS
6
Ethernet
This chapter provides a brief description of the origins of Ethernet, the Ethernet frame format and the role of switched Ethernet in avionics applications
ALOHA Net
In 1970, the University of Hawaii deployed a packet radio system called the “ALOHA network” [Norman Abramson; see Figure 4] to provide data communications between stations located on different islands There was no centralized control among the stations; thus, the potential for collisions (simulta-neous transmission by two or more stations) existed
Chapter 2 Ethernet
Figure 4. ALOHA Net
The ALOHA Protocol
1 If you have a message to send, send the message, and
2 If the message collides with another transmission, try resending the message later using a back-off strategy Issues
? No central coordination
? Collisions lead to non-deterministic behavior
Ethernet Local Area Networks (Broadcast Media)
In 1972, Robert Metcalfe and David Boggs at Xerox Palo Alto Research Center built upon the ALOHA network idea and used a coaxial cable as the communication medium and invented Ethernet (see Figure 5) Ethernet is similar to the ALOHA
protocol in the sense that there is no centralized control and transmissions from different stations (hosts) could collide The Ethernet communication protocol is referred to as “CSMA/CD” (Carrier Sense, Multiple Access, and Collision Detection) Carrier Sense means that the hosts can detect whether the medium (coaxial cable) is idle or busy Multiple Access means that multiple hosts can be connected to the common me-dium Collision Detection means that, when a host transmits, it can detect whether its transmission has collided with the transmission of another host (or hosts) The original Ethernet data rate was 2 94Mbps
Figure 5. Ethernet Local Area Networks (Broadcast Media)
The Ethernet Protocol
1 If you have a message to send and the medium is idle, send the message
2 If the message collides with another transmission, try sending the message later using a suitable back-off strategy Issues
? No central coordination
? Collisions lead to non-deterministic behavior
Ethernet Using Category 5 UTP Copper Twisted Pairs
The most common electrical form of Ethernet today is based on the use of twisted pair copper cables Typically, cables are point-to-point, with hosts directly connected to a switch In the case of Fast Ethernet (100Mbps), two pairs of Category 5 UTP copper wire are used for Tx and Rx, respectively In the case of transmission, each 4-bit nibble of data is encoded by 5 bits prior to transmission This is referred to as “4B/5B encoding” and results in a transmission clock frequency of 125Mbps, since 5 bits are sent for every 4 bits of data Since there are twice as many 5-bit patterns as 4-bit ones, it is possible to ensure that every transmitted pattern is able to provide good clock synchronization (not too many 0’s or 1’s in a row) for reliable transmission of data Some of the 5-bit patterns are used to represent control codes
Coaxial Cable (Bus Architecture)
Ethernet Frame Format
As Figure 6 illustrates, IEEE 802 3 defines the format of an Ethernet transmission to include a 7-byte Preamble, a Start Frame Delimiter (SFD), the Ethernet frame itself, and an Inter-Frame Gap (IFG) consisting of at least 12 bytes of idle symbols The Ethernet frame begins with the Ethernet header,
byte 7 1 6 6 2 46 - 1500 4
12
Figure 6. Ethernet Frame Format
7
Doing Away with Contention
To do away with contention (collisions), and hence the indeterminacy regarding how long a packet takes to travel from sender to receiver, it is necessary to move to Full-duplex Switched Ethernet Full-duplex Switched Ethernet eliminates the possibility of transmission collisions like the ones that occur when using Half-duplex Based Ethernet As shown in Figure 7, each Avionics Subsystem— autopilot, heads-up dis-play, etc — is directly connected to a Switch over a full-duplex link that comprises two twisted pairs — one pair for transmit (Tx) and one pair for receive (Rx) (The switch comprises all the components contained in the large box ) The switch is able to buffer packets for both reception and transmission
Now, let’s look at what goes on within the switch, as shown in Figure 7
which consists of a 6-byte destination address, followed by a 6-byte source address, and a type field The Ethernet payload follows the header The frame concludes with a Frame Check Sequence (FCS) for detecting bit errors in the transmitted frame, followed by an IFG The length of an Ethernet frame can vary from a minimum of 64 bytes to a maximum of 1518 bytes
Ethernet communication (at the link level) is connectionless Acknowledgments must be handled at higher levels in the protocol stack
Full-duplex, Switched Ethernet The Scenario
Half-duplex Mode Ethernet is another name for the original Ethernet Local Area Network discussed earlier As we ex-plained, there is an issue when multiple hosts are connected to the same communication medium as is the case with coaxial cable, depicted in Figure 5, and there is no central coordination It is possible for two hosts to transmit “simulta-neously” so that their transmissions “collide ” Thus there is a need for the hosts to be able to detect transmission collisions When a collision occurs (two or more hosts attempting to transmit at the same time), each host has to retransmit its
data Clearly, there is a possibility that they will retransmit at the same time, and their transmissions will again collide To avoid this phenomenon, each host selects a random trans-mission time from an interval for retransmitting the data If a collision is again detected, the hosts selects another random time for transmission from an interval that is twice the size of the previous one, and so on This is often referred to as the binary exponential backoff strategy
Since there is no central control in Ethernet and in spite of the random elements in the binary exponential backoff strategy, it is theoretically possible for the packets to repeatedly collide What this means is that in trying to transmit a single packet, there is a chance that you could have an infinite chain of colli-sions, and the packet would never be successfully transmitted Therefore, in half-duplex mode it is possible for there to be very large transmission delays due to collisions This situation is unacceptable in an avionics data network
So, what was required (and what was implemented in AFDX) was an architecture in which the maximum amount of time it would take any one packet to reach its destination is known That meant ridding the system of contention
Figure 7. Full-Duplex, Switched Ethernet Example
The Rx and Tx buffers in the switch are both capable of storing multiple incoming/outgoing packets in FIFO (first-in, first out) order The role of the I/O processing unit (CPU) is to move packets from the incoming Rx buffers to the outgoing Tx buffers It does this by examining each arriving packet that is next in line in the Rx buffer to determine its destination address (virtual link identifier) and then goes to
the Forwarding Table to determine which Tx buffers are to receive the packet The packet is then copied into the Tx buf-fers, through the Memory Bus, and transmitted (in FIFO order) on the outgoing link to the selected Avionic Subsystem or to another switch This type of switching architecture is referred to as store and forward
Consequently, with this full-duplex switch architecture the contention encountered with half-duplex Ethernet is eliminat-ed, simply because the architecture eliminates collisions Theoretically, a Rx or Tx buffer could overflow, but if the buffer requirement in an avionics system are sized correctly, over-flow can be avoided
There are no collisions with full-duplex switched Ethernet, but packets may experience delay due to congestion in
the switch
Instead of collisions and retransmissions, switching architec-ture may result in jitter, due to the random delay introduced by one packet waiting for another to be transmitted The extent of jitter introduced by an End System and Switch must be controlled if deterministic behavior of the overall Avionics System is to be achieved
Reducing Wire Runs and Weight
In addition to the enhancements already described, AFDX delivers some additional benefits, compared to ARINC 429 Figure 8 shows some distinctions between ARINC 429 and AFDX In ARINC 429, a twisted pair must link every device that receives the azimuth signal form the inertial platform The point-to-multi-point and unidirectional properties of ARINC 429 means that the avionics system must include an ARINC 429 bus for each communication path In a system with many end points, point-to-point wiring is a major overhead This can lead to some huge wiring harnesses, with the added weight that goes along with them But in the case of AFDX, as shown in Figure 8b, each signal
is connected to the switch only once so that no matter how many subsystems require the azimuth signal from the inertial platform, they need not be connected individually to the inertial platform
With ARINC 429, a transmitter can fan out to only 20 receiv-ers With AFDX, the number of fan-outs from the inertial platform is limited only by the number of ports on the switch Also, by cascading switches, the fan-out can be easily in-creased as needed
Figure 8. AFDX versus ARINC 429 architecture
8
9
End Systems and Avionics Subsystems
As Figure 9 shows, an Avionics computer system connects to the AFDX network through an End System In general, an Avionics computer system is capable of supporting multiple Avionics subsystems Partitions provide isolation between Avi-onics subsystems within the same Avionics computer system This isolation is achieved by restricting the address space of each partition and by placing limits on the amount of CPU time allotted to each partition The objective is to ensure that an errant Avionics subsystem running in one partition will not affect subsystems running in other partitions
Avionics applications communicate with each other by send-ing messages using communication ports The specification
of an operating system API for writing portable avionics ap-plications can be found in ARINC 653 In particular, ARINC 653 defines two types of communications ports – sampling and
Chapter 3 End Systems and Avionics Subsystems
Figure 9. End Systems and Avionics Subsystems Example
queuing ports Accordingly, it is necessary that End Systems provide a suitable communications interface for support-ing sampling and queuing ports The AFDX ports, defined in ARINC 664, Part 7, include sampling, queuing and SAP ports The AFDX sampling and queuing ports correspond to ARINC 653 sampling and queuing ports, respectively AFDX intro-duces a third port type called a Service Access Point (SAP) port SAP ports are used for communications between AFDX system components and non-AFDX systems More about this in the next chapter
End Systems are identified using two 8-bit quantities: a Network ID and an Equipment ID These may be combined into a single 16-bit quantity As we shall see, the End System identification is used in forming source MAC addresses and unicast IP addresses
Avionics Computer System
Chapter 4 AFDX Communications Ports
AFDX Communications Ports
Avionics subsystems use communications ports to send messages to each other Communication ports, which are typically part of the operating system API, provide a program-ming mechanism for sending and receiving messages Two types of communications ports play a role in Avionics subsys-tems: sampling and queuing ports
AFDX End Systems must provide both sampling and queuing port services, as described in ARINC 653
As Figure 10 and Figure 11 show, sampling and queuing ports differ mainly in reception A sampling port has buffer stor-age for a single message; arriving messages overwrite the message currently stored in the buffer Reading a message from a sampling port does not remove the message from the buffer, and therefore it can be read repeatedly Each sampling port must provide an indication of the freshness of the mes-sage contained in the port buffer Without this indication, it would be impossible to tell whether the transmitting Avionics subsystem has stopped transmitting or is repeatedly sending the same message
A queuing port has sufficient storage for a fixed number of messages (a configuration parameter), and new messages are appended to the queue Reading from a queuing port removes the message from the queue (FIFO)
Typical programming interfaces for sending and receiving messages are as follows:
?Send_Msg(port_ID, message)
?Recv_Msg(port_ID, message)
The port_ID identifies the communication port, and the mes-sage argument points to a buffer that either contains the message to be sent or is available to receive a new message from the port
Arriving message
overwrites the
current message
stored in the
port buffer
Application reading
a message from the
port does not remove
the message
Figure 10. Sampling Port at Receiver
Figure 11. Queuing Port at Receiver
Arriving message
is appended to
the queue
Application reading
a message from
the port removes
the message
10
11
Virtual Links
In a traditional Ethernet switch, incoming Ethernet frames are routed to output links based on the Ethernet destina-tion address In AFDX, a 16-bit value called a Virtual Link ID is used to route Ethernet frames in an AFDX network Figure 12 provides the format of the Ethernet destination address in an AFDX network
The switches in an AFDX network are “configured” to route an incoming Ethernet frame to one or more outgoing links An important property of an AFDX network is that Ethernet frames associated with a particular Virtual Link ID must origi-nate at one, and only one, End System The AFDX switches
Chapter 5 Virtual Links: Packet Routing in AFDX
Figure 12. Format of Ethernet Destination Address in AFDX Network
Figure 13. Packet Routing Example
are configured to deliver frames with the same Virtual Link ID to a predetermined set of End Systems Thus, a virtual link originates at a single End System and delivers packets to a fixed set of End Systems; this is analogous to an ARINC 429 multi-drop bus
In the example in Figure 13, when the Source End System (1) sends an Ethernet frame with a Virtual Link ID (VLID) = 100 to the network, the AFDX switches deliver the frame to a predetermined set of destination End Systems (2 and 3) More than one virtual link can originate at an End System, and each virtual link can carry messages from one or more communication ports
12
Chapter 6 Message Flows
Message Flows
When an application sends a message to a communications port, the source End System, the AFDX network, and the des-tination End Systems are configured to deliver the message to the appropriate receive ports
Figure 14 shows a message M being sent to Port 1 by the Avi-onics subsystem End System 1 encapsulates the message in an Ethernet frame and sends the Ethernet frame to the AFDX Switched Network on Virtual Link 100 (the Ethernet destina-tion address specifies VLID 100) The forwarding tables in the network switches are configured to deliver the Ethernet frame to both End System 2 and End System 3 The End Systems that receive the Ethernet frame are configured so that they are able to determine the destination ports for the message contained in the Ethernet frame In the case shown in Figure 14, the message is delivered by End System 2 to port 5 and by End System 3 to port 6
The information used by the destination End System to find the appropriate destination port for the message is contained in headers within the Ethernet payload
Figure 15 shows the headers that make up the Ethernet pay-load The Ethernet payload consists of the IP packet (header
Figure 14. Message Sent to Port 1 by the Avionics Subsystem
Figure 15. Ethernet Frame with IP and UDP Headers and Payloads
byte
14
4
and payload) The IP packet payload contains the UDP packet (header and payload), which contains the message sent by the Avionics subsystem The Pad is necessary only when the UDP payload is smaller than 18 bytes; in this case, the pad plus the UDP payload will equal 18 bytes With UDP payloads greater than or equal to 18 bytes, there is no Pad field Note that the diagram applies only to UDP payloads that have not been fragmented among multiple IP payloads An important function of the IP header is to provide fragmentation control for large UDP packets
The IP header contains a destination End System Identifica-tion and partition identifiers or is a multicast address In the latter case, the IP destination address contains the Virtual Link ID (the Virtual Link ID in the Destination Ethernet ad-dress) The UDP header contains both source and destination UDP port numbers In general, there is enough information in these headers for an End System to determine the destination port for the message Similarly, sufficient information associ-ated with a transmitting AFDX communication port exists for the source End System to construct the appropriate headers when building the Ethernet frame that contains the message Appendix A, “AFDX Frame Addressing and Header Structures”, provides additional details on the contents and format of the Ethernet frames
13
Chapter 7 Redundancy Management
Redundancy Management
There are two independent switched networks in an AFDX system, the A and B Networks Each packet transmitted by an End System is sent on both networks Therefore, under normal operation, each End System will receive two copies of each packet (see Figure 16)
Figure 16. A and B Networks
Figure 17. AFDX Frame and Sequence Number
Figure 18. Receive Processing of Ethernet Frames
End Systems need a way to identify corresponding pack-ets (replicas) that arrive on the A and B networks In AFDX, all packets transmitted over virtual link are provided with a
1-byte sequence number field The sequence number field appears just before the FCS field in the Ethernet frame This
means that, in AFDX, one less byte is available to the IP/UDP payload The sequence numbers start with 0, continue to 255, and then roll over to 1 The sequence number 0 is reserved for End System Reset Sequence numbers are provided on a per-Virtual Link basis An Ethernet frame with an embedded sequence number is referred to as an AFDX frame
Figure 17 applies when the UDP payload is between 17 and 1471 bytes If the UDP payload is smaller than 17 bytes, then a Pad field is introduced between the UDP Payload and the Sequence Number fields
On a per-virtual link and per-network port basis, the receiving End System checks that the sequence numbers on successive frames are in order This is referred to as “Integrity Checking ” After Integrity Checking is complete, the End System deter-mines whether to pass the packet along or drop it because its replica has already been sent along This is called Redun-dancy Management Figure 18 summarizes the process
14
Chapter 8 Virtual Link Isolation
Virtual Link Isolation
As mentioned previously, the 100 Mbps link of an End System can support multiple virtual links These virtual links share the 100 Mbps bandwidth of the physical link Figure 19 shows three virtual links being carried by a single 100 Mbps physical link The figure also shows that the messages sent on AFDX Ports 1, 2, and 3 are carried by Virtual Link 1 Messages sent on AFDX Ports 6 and 7 are carried by Virtual Link 2, and mes-sages sent on AFDX Ports 4 and 5 are carried by Virtual Link 3
Just as partitions are used to isolate Avionics subsystems from one another, a similar mechanism is required to isolate individual virtual links, in order to prevent the traffic on one virtual link from interfering with traffic on other virtual links using the same physical link This is done by limiting the rate at which Ethernet frames can be transmitted on a virtual link and by limiting the size of the Ethernet frames that can be transmitted on a virtual link
Each virtual link is assigned two parameters:
? Bandwidth Allocation Gap (BAG), a value ranging in powers of 2 from 1 to 128 milliseconds
? Lmax, the largest Ethernet frame, in bytes, that can be transmitted on the virtual link
The BAG represents the minimum interval in milliseconds between Ethernet frames that are transmitted on the virtual link For example, if a virtual link with VLID 1 has a BAG of 32 milliseconds, then Ethernet packets are never sent faster than one packet every 32 milliseconds on VLID 1 If VLID 1 has an Lmax of 200 bytes, then the maximum bandwidth on VLID 1 is 50,000 bits per second (200* 8*1000/32)
Figure 19. Three Virtual Links Carried by a Physical Link
The table below indicates the allowable values for the BAG and the corresponding frequencies
Table 1. Allowable BAG Values
BAG
milliseconds
Hz 1 1000 2 500 4 250 8 125 16 62 5 32 31 25 64 15 625
128
7 8125
Choosing the BAG and Lmax for a Virtual Link
The choice of BAG for a particular virtual link depends on the requirements of the AFDX ports that are being provided link-level transport by the virtual link For example, suppose an Avionics subsystem is sending messages on three AFDX communications ports that are being carried by the same virtual link Let’s assume the message frequencies on the ports are 10 Hz, 20 Hz, and 40 Hz, respectively The total frequency of the combined messages (they will be combined on the same virtual link) is 70 Hz The average period of the message transmissions is 14 4ms Accordingly, to provide adequate bandwidth on the virtual link, we should select a BAG that is less than 14 4 ms The first available BAG is 8 ms, which corresponds to a frequency of 125 Hz With a BAG of 8 ms, we are guaranteed that the virtual link is able to trans-port the combined messages from the three ports without any backlog
The source End System is required to enforce BAG restrictions for each outgoing virtual link A number of virtual link sched-uling algorithms can be used by the End System
Lmax should be chosen to accommodate the largest Ethernet frame to be transmitted by these ports on the virtual link
15
Chapter 9 Virtual Link Scheduling
Virtual Link Scheduling
Each sending AFDX communication port is associated with a virtual link Messages sent to the communication port are en-capsulated within UDP, IP, and Ethernet headers and placed in the appropriate virtual link queue for transmission The trans-mission of Ethernet frames in a virtual link queue is scheduled by the End System’s Virtual Link Scheduler The Virtual Link Scheduler is responsible for scheduling transmissions of all the virtual links originating with this End System Figure 20 summarizes the Virtual Link Scheduling scenario The Virtual Link Scheduler is responsible for ensuring that each virtual link conforms to its assigned bandwidth limita-tion Not only must the Virtual Link Scheduler ensure the BAG and Lmax limitations for each virtual link, but it is also re-sponsible for multiplexing all of the virtual link transmissions so that the amount of jitter introduced by the multiplexing is within acceptable bounds Figure 20. Virtual Link Scheduling
The timing of messages sent to an AFDX communications port is controlled by the Avionics subsystems and require-ments of various attached devices For example, a sensor may be sending readings at a 10 Hz rate Jitter may be
introduced if the message arrives at a non-empty virtual link queue Similarly, multiplexing all the virtual link queues into the Redundancy Management Unit and subsequent transmis-sion on the physical links can introduce additional jitter The ARINC 664 specification requires that, in transmission, the maximum allowed jitter on each virtual link at the output of the End System comply with both of the following formulas:
Nbw is the link bandwidth (100 Mbps) The first formula rep-resents a bound on the jitter arising from an Ethernet frame
being delayed by a frame from each of the other virtual
links The second formula is a hard limit, independent of the number of virtual links These requirements are necessary to demonstrate the overall “determinism” of an AFDX network
Once a frame is selected from a virtual link queue for
transmission, the per-VL sequence number is assigned and the frame is sent to the Redundancy Management Unit for replication (if necessary) and transmission on the physical
link(s) The sequence numbers are not assigned to AFDX frames sooner than actual virtual link scheduling because of the sub-VL mechanism If a virtual link has more than
one sub-VL, the sequence number cannot be assigned to an AFDX frame until it is actually chosen by the Virtual Link
Scheduler for transmission Figure 21. Virtual Link Scheduling
Figure 21 depicts a virtual link with three sub-VLs The Virtual Link Scheduler treats these sub-VLs as a single virtual link for scheduling purposes However, packets are selected for transmission from the sub-VL queues in a round-robin man-ner Clearly, sequence numbers cannot be assigned to the packets in the sub-VL queues until they are actually selected for transmission by the Virtual Link Scheduler If there is only a single sub-VL (the usual case), sequence numbers can be assigned as the Ethernet frames are inserted in the virtual link queue
16
Jitter
Virtual Link scheduling consists of two components: packet regulation and multiplexing
Figure 22 shows the role of the Virtual Link Regulators in pacing the frames from the virtual link queues to create zero-jitter output streams The Virtual Link Scheduler is also responsible for multiplexing the regulator outputs into the Redundancy Management Unit for replication and transmis-sion on the physical links
Chapter 10 Jitter
Figure 22. Role of Virtual Link Regulation
The outputs of the Regulator consist of regulated streams of Ethernet frames Jitter is introduced when the Regulator outputs are combined by the Virtual Link Scheduler MUX;
Ethernet frames arriving at input to the MUX at the same time will experience queuing delay (jitter)
Selects frames for transmission Replicates
Ethernet frames Regulator Input Regulator Output
17
Introduction
Avionics subsystem designers are reasonably free to choose the message structure that bests suits the Avionics applica-tion The messages are contained in the payload of the UDP packet In general, the interpretation of the messages is
determined by agreement between the Avionics applications ARINC 664, Part 7, identifies two types of message struc-tures: explicit and implicit Explicit message structures include format information that enables the receiver to correctly interpret the data Implicit message structures do not contain any descriptive information to aid the receiver in interpreting the data; consequently, they use network bandwidth more efficiently
This section discusses the ARINC 664 Implicit Message
Structure formats Since there is no explicit format informa-tion contained in an implicit message structure, the Avionics
application needs a way to identify the message format of
the received data This is accomplished by associating implicit message structures with an AFDX receive port The applica-tion associates the message structure based on the UDP port
number where the message is received
With the Internet, certain well-known UDP port numbers cor-respond to specific applications: port 69 is used by the Trivial File Transport Protocol (TFTP); port 80 is used by the Hypertext Transport Protocol (HTTP), and so on An Internet Assigned Number Authority (IANA) manages the space of UPD port numbers UPD port numbers fall into three groups:? Assigned port numbers (well-known ports): 0–1023 ? Registered port numbers: 1024–4951 ? Dynamic/Private port numbers: 49152–65535
Although AFDX/ARINC 664 is a closed network, UDP port
numbers should be selected from the Dynamic/Private range of numbers The reason for this is that there could be po-tential conflicts with the standard port number assignments when a gateway is used to communicate between the AFDX network and the Internet
Implicit Message Structures
ARINC 664, Part 7, presents a more complete description of the format of implicit message structures A limited number of data types are defined, including the following: ? Signed_32 Integer ? Signed_64 Integer ? Float_32? Float_64
Chapter 11 AFDX Message Structures
? Boolean ? String ? Opaque Data
The standard also requires that the primitive data types be aligned on their natural boundaries For example, Float_64 must be aligned on a 64-bit boundary Address 0 is consid-ered the beginning of the UDP payload; all alignments are relative to Address 0
The first 4 bytes of the message structure are reserved After this, the basic message structure consists of a 4-byte word called the Functional Status Set, followed by up to four data sets The basic message structure can be repeated an arbi-trary number of times to form the message structure Figure 23 depicts two message structures The one on the left con-sists of two data sets, Data Set 1 and Data Set 2 The Func-tional Status Set has two functional status bytes, FS1 and FS2, which correspond to the Data Sets 1 and 2, respectively
Figure 23. Two Message Structures
AFDX Message Structure
ARINC 664Message Structure
Functional Status (FS)
– No Data
– Normal Operation – Functional Test – No Computed Data
18
The functional status of each data set is encoded in the cor-responding Functional Status byte There are four possible states: No Data, Normal Operation, Functional Test, and No Computed Data Clearly, the data must be grouped into data sets so that the functional status applies to all the data in the data set
The message structure depicted above on the right consists of two basic message structures and a total of five data sets and five corresponding functional statuses
ARINC 429 Labels
Figure 24 shows how ARINC 429 data can be accommodated using the ARINC 664 message structures The opaque primi-tive data type is used so that the interpretation of the data is left up to the application (as usual)
Figure 24. ARINC 664 Message Structures
Data Set 1
Data Set 1
Data Set 1
19
The AFDX Protocol Stack
This tutorial concludes with a description of the overall AFDX protocol stacks for transmission and reception The protocol layers are divided into AFDX communications services, UDP transport layer, and link level (virtual link) services
Transmission
The Tx protocol begins with a message being sent to an AFDX port The UDP transport layer is responsible for adding the UDP header, which includes the appropriate source and destination UDP port numbers These numbers are, in most cases, determined by the system configuration and are fixed for each AFDX communications port In the case of a SAP port, the application specifies the IP and UDP destination ad-dresses dynamically
Chapter 12 The AFDX Protocol Stack
Figure 25. AFDX Tx Protocol Stack
The IP network layer receives the UDP packet and determines whether it needs to be fragmented The IP network layer uses the appropriate virtual link’s Lmax to determine whether fragmentation is necessary The IP header is added, and IP checksum is calculated for each fragment The IP layer adds the Ethernet header and enqueues the Ethernet frame in the appropriate sub-VL queue The (virtual) link layer is responsi-ble for scheduling the Ethernet frames for transmission, add-ing the sequence numbers (on a per-VL basis), and passing the frames to the Redundancy Management Unit, where the frames are replicated (if necessary) and the Ethernet source address is updated with the physical port ID on which the frame is transmitted
AFDX Services
Message written to AFDX port
End System Tx Packets
Reception
Reception is the reverse of transmission The process starts with the reception of an Ethernet frame, which is checked for correctness using the Frame Check Sequence (FCS) If there is no error, the FCS is stripped and the AFDX frame is passed through Integrity Checking and Redundancy Management These steps are carried out at the (virtual) link level The re-sulting IP packet is passed on to the IP network level The network level is responsible for checking the IP checksum field and the UDP packet reassembly, if necessary The UDP packet is passed to the UDP transport layer to deliver (DE-MUX) the AFDX message to the appropriate UDP port
End System Rx Packets
Figure 26. AFDX Rx Protocol Stack
20
ISIS协议题目有答案
I S I S协议题目有答案 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
一、填空题：（每空4分） 1. IS-IS的IS是___intermediate___________的缩写。 2.IS-IS最早是为_CLNS（connectless network service 无连接网络服务）设计的 动态路由协议，是一种基于_链路状态算法___的IGP（内部网关）路由协议。 3.ISIS支持的网络类型有___P-2-P网络__，__广播网络__，_IS-IS协议不能真正 支持NBMA网络，可以将NBMA链路配置成子接口来支持_。 4.IS-IS的LSP的生存时间为 1200秒 5.ISIS协议中的DIS相当于OSPF中的 DR, SysID相当于OSPF中的 router ID。 二、多选题：（每题5分） 1.LSP标识由那些部分组成___ABD______ A)系统标识System ID B)伪节点ID C)LSP序列号 D)LSP编号 2.一个IS-IS路由器想和其它区域的路由器形成邻居关系，它可以是 _BC____ A)L1路由器 B)L2路由器 C)L1/L2路由器 D)类型没有限制 3.IS-IS的PDU有如下ABD_____几种类型 A)HELLO B)LSP C)LSP ACK D)CSNP
4.下列说法正确的是：ABCD A、区域之间通过L2(L1/L2)路由器相连接 B、一个路由器目前最多有3个Area ID(IOS和VRP的实现) C、一个路由器必须整个属于某个区域，而不能象OSPF那样是同一台路由器上不同的接口可 以属于不同的区域 D、对于Level-1路由器来说，只有属于同一区域才可以建立邻居，对于Level-2路由器则 没有此同一区域限制。 简答题：（每题20分） 1.ISIS协议中DIS的选取规则 1)DIS由LAN IIH报文选举，具备最高优先级的路由器会被当选。如果所有路由器 优先级相同，则最高MAC地址者当选 2)Level-1和Level-2的DIS是分别选举的，选举结果可能不是同一个DIS 3)DIS发送Hello数据包的时间间隔是普通路由器的1/3，这样可以保证DIS失 效可以被快速检测到 4)与OSPF不同，它的选举是抢占式，可预见的；IS-IS中不存在备份DIS，当一 个DIS不能工作时，直接选举另一个 5)同一网段的所有路由器形成邻接关系（OSPF中DR-other之间是不形成邻接关系 的） 2. 简述IS-IS协议与OSPF协议不同点 IS-IS最初是为ISO的标准协议，为CLNS（connectless network service 无连接网络服务）设计的，后来增加了对IP的支持；而OSPF一开始就是IETF为IP网络设计的；由于IS-IS历史上是为CLNS路由而制定的，发展比较缓慢，对于IP的支持很多地方需要改进，虽然已经提出了draft，但大部分还没有形成RFC，CNLP （connectless network protocol 无连接网络协议）和IP双环境使用的优势并不明显，是一个不是很成熟的协议； OSPF是专门为IP设计的，更适合IP的路由，发展成熟，标准化程度高，支持厂商多，使用多缺点暴露多，改进也多。 IS-IS协议直接在链路层上运行，报文直接封装在链路层报文中，支持CLNS、IP 等多种协议；OSPF报文封装在IP中，只支持IP协议； IS-IS协议中整个路由器只能全部属于一个区域，区域边界位于两个路由器之间，路由器的LSDB按Level来维护；而OSPF按接口来，一个路由器可以属于多个区域，为每个区域维护一个LSDB数据库； OSPF通过特殊的区域ID Area0区来定义骨干区，而IS-IS是通过连续的L2路由器来组成骨干区； IS-IS的采用的Hello协议比较简单，OSPF比较复杂；而且IS-IS检查比较宽松，邻居之间的Hello和Dead等间隔不一定必须一样，不象OSPF要求必须一致才能形成邻居关系；
对赌协议主要模式解析
对赌协议主要模式解析 对赌一词听来刺激，其实和赌博无甚关系。对赌协议是投资方与融资方在达成协议时，双方对于未来不确定情况的一种约定。如果约定的条件出现，投资方可以行使一种权利；如果约定的条件不出现，融资方则行使一种权利。所以，对赌协议实际上就是期权的一种形式。 通过条款的设计，对赌协议可以有效保护投资人利益，但由于多方面的原因，对赌协议在我国资本市场还没有成为一种制度设置，也没有被经常采用。但在国际企业对国内企业的投资中，对赌协议已经被广泛采纳。在创业型企业投资、成熟型企业投资中，都有对赌协议成功应用的案例，最终企业也取得了不错的业绩。研究国际企业的这些对赌协议案例，对于提高我国上市公司质量，也将有极为现实的指导意义。 三种应用类型 1．创业型企业中的应用 摩根士丹利等机构投资蒙牛，是对赌协议在创业型企业中应用的典型案例。 1999年1月，牛根生创立了“蒙牛乳业有限公司”，公司注册资本100万元。后更名为“内蒙古蒙牛乳业股份有限公司”（以下简称“蒙牛乳业”）。2001年底摩根士丹利等机构与其接触的时候，蒙
牛乳业公司成立尚不足三年，是一个比较典型的创业型企业。 2002年6月，摩根士丹利等机构投资者在开曼群岛注册了开曼公司。2002年9月，蒙牛乳业的发起人在英属维尔京群岛注册成立了金牛公司。同日，蒙牛乳业的投资人、业务联系人和雇员注册成立了银牛公司。金牛和银牛各以1美元的价格收购了开曼群岛公司50%的股权，其后设立了开曼公司的全资子公司——毛里求斯公司。同年10月，摩根士丹利等三家国际投资机构以认股方式向开曼公司注入约2597万美元（折合人民币约2.1亿元），取得该公司90.6%的股权和49%的投票权，所投资金经毛里求斯最终换取了大陆蒙牛乳业66.7%的股权，蒙牛乳业也变更为合资企业。 2003年，摩根士丹利等投资机构与蒙牛乳液签署了类似于国内证券市场可转债的“可换股文据”，未来换股价格仅为0.74港元／股。通过“可换股文据”向蒙牛乳业注资3523万美元，折合人民币2.9亿元。“可换股文据”实际上是股票的看涨期权。不过，这种期权价值的高低最终取决于蒙牛乳业未来的业绩。如果蒙牛乳业未来业绩好，“可换股文据”的高期权价值就可以兑现；反之，则成为废纸一张。 为了使预期增值的目标能够兑现，摩根士丹利等投资者与蒙牛管理层签署了基于业绩增长的对赌协议。双方约定，从2003年～2006年，蒙牛乳业的复合年增长率不低于50%。若达不到，公司管理层将输给摩根士丹利约6000万～7000万股的上市公司股份；如果业绩增长达到目标，摩根士丹利等机构就要拿出自己的相应股份奖励给蒙牛
OSPF协议详解分析
OSPF 学习笔记 OSPF 协议号是89，也就是说在ip 包的protocol 中是89，用ip 包来传送 数据包格式: 在OSPF 路由协议的数据包中，其数据包头长为24 个字节，包含如下8 个字段： * Version number-定义所采用的OSPF 路由协议的版本。 * Type-定义OSPF 数据包类型。OSPF 数据包共有五种： * Hello-用于建立和维护相邻的两个OSPF 路由器的关系，该数据包是周期性地发送的。 * Database Description-用于描述整个数据库，该数据包仅在OSPF 初始化时发送。 * Link state request-用于向相邻的OSPF 路由器请求部分或全部的数据，这种数据包是在当 路由器发现其数据已经过期时才发送的。 * Link state update-这是对link state 请求数据包的响应，即通常所说的LSA 数据包。 * Link state acknowledgment-是对LSA 数据包的响应。 * Packet length-定义整个数据包的长度。 * Router ID-用于描述数据包的源地址，以IP 地址来表示，32bit * Area ID-用于区分OSPF 数据包属于的区域号，所有的OSPF 数据包都属于一个特定 的OSPF 区域。 * Checksum-校验位，用于标记数据包在传递时有无误码。 * Authentication type-定义OSPF 验证类型。 * Authentication-包含OSPF 验证信息，长为8 个字节。 FDDI 或快速以太网的Cost 为1，2M 串行链路的Cost 为48，10M 以太网的Cost 为10 等。 所有路由器会通过一种被称为刷新（Flooding）的方法来交换链路状态数据。Flooding 是指路由器将其LSA 数据包传送给所有与其相邻的OSPF 路由器，相邻路由器根据其接收到的链路状态信息 更新自己的数据库，并将该链路状态信息转送给与其相邻的路由器，直至稳定的一个过程。当路由 器有了一个完整的链路状态数据库时，它就准备好要创建它的路由表以便能够转发数据流。CISCO 路由器上缺省的开销度量是基于网络介质的带宽。要计算到达目的地的最低开销，链路状态型路由选择协议（比如OSPF）采用Dijkstra 算法，OSPF 路由表中最多保存 6 条等开销路由条目以进行负 载均衡，可以通过"maximum-paths" 进行配置。如果链路上出现fapping 翻转，就会使路由器不停 的计算一个新的路由表，就可能导致路由器不能收敛。路由器要重新计算客观存它的路由表之前先 等一段落时间，缺省值为 5 秒。在CISCO 配置命令中"timers spf spf-delay spy-holdtime" 可以对两次连续SPF 计算之间的最短时间（缺省值10 秒）进配置。 路由器初始化时Hello 包是用224.0.0.5 广播给域内所有OSPF 路由器，选出DR 后在用224.0.0.6 和DR，BDR 建立邻接。DR 用224.0.0.5 广播给DRother LSA BDR 也是 DRother 用224.0.0.6 广播LSA 给DR 和BDR DR 是在一个以太网段内选举出来的，如果一个路由器有多个以太网段那么将会有多个 DR 选举；DR 的选择是通过OSPF 的Hello 数据包来完成的，在OSPF 路由协议初始化的过程中，会通过Hello 数据包在一个广播性网段上选出一个ID 最大的路由器作为指定
OSPF路由协议各种类型详解
OSPF各种类型详解 一、OSPF数据包类型 1.Hello包：用于建立和维护相邻的两个OSPF路由器的邻接关系，该数据包是周期性地发送的。 2.Database Description（数据库描述包DBD）：用于描述整个数据库，该数据包仅在OSPF初始化时发送。 3.Link state request（链路状态请求包LSQ）：用于向相邻的OSPF路由器请求部分或全部的数据，这种数据包是在当路由器发现其数据已经过期时才发送的。 4.Link state update（链路状态更新包LSU）：这是对link state请求数据包的响应，即通常所说的LSA数据包。 5.Link state acknowledgment（链路状态确认包LSAck）：是对LSA数据包的确认，以确保可靠地传输和信息交换。 二、OSPF网络类型 OSPF链路类型有3种：点到点，广播型，NBMA。在3种链路类型上扩展出5种网络类型：点到点，广播，NBMA，点到多点，虚链路。其中虚链路较为特殊，不针对具体链路，而NBMA链路对应NBMA和点到多点两种网络类型。 以上是RFC的定义，在Cisco路由器的实现上，我们应记为3种链路类型扩展出8种网络类型，其中NBMA链路就对应5种，即在RFC的定义基础上又增加了3种类型。首先分析一下3种链路类型的特点： 1. 点到点：一个网络里仅有2个接口，使用HDLC或PPP封装，不需寻址，地址字段固定为FF； 2. 广播型：广播型多路访问，目前而言指的就是以太网链路，涉及IP 和Mac，用ARP 实现二层和三层映射； 3. NBMA：网络中允许存在多台Router，物理上链路共享，通过二层虚链路（VC）建立逻辑上的连接。
对赌协议的运用及案例
对赌协议的运用及案例 对赌一词听来刺激，其实和赌博无甚关系。对赌协议是投资方与融资方在达成协议时，双方对于未来不确定情况的一种约定。如果约定的条件出现，投资方可以行使一种权利；如果约定的条件不出现，融资方则行使一种权利。所以，对赌协议实际上就是期权的一种形式。 通过条款的设计，对赌协议可以有效保护投资人利益，但由于多方面的原因，对赌协议在我国资本市场还没有成为一种制度设置，也没有被经常采用。但在国际企业对国内企业的投资中，对赌协议已经被广泛采纳。在创业型企业投资、成熟型企业投资中，都有对赌协议成功应用的案例，最终企业也取得了不错的业绩。研究国际企业的这些对赌协议案例，对于提高我国上市公司质量，也将有极为现实的指导意义。 三种应用类型 1．创业型企业中的应用 摩根士丹利等机构投资蒙牛，是对赌协议在创业型企业中应用的典型案例。 1999年1月，牛根生创立了“蒙牛乳业有限公司”，公司注册资本100万元。后更名为“内蒙古蒙牛乳业股份有限公司”（以下简称“蒙牛乳业”）。2001年底摩根士丹利等机构与其接触的时候，蒙牛乳业公司成立尚不足三年，是一个比较典型的创业型企业。
2002年6月，摩根士丹利等机构投资者在开曼群岛注册了开曼公司。2002年9月，蒙牛乳业的发起人在英属维尔京群岛注册成立了金牛公司。同日，蒙牛乳业的投资人、业务联系人和雇员注册成立了银牛公司。金牛和银牛各以1美元的价格收购了开曼群岛公司50%的股权，其后设立了开曼公司的全资子公司——毛里求斯公司。同年10月，摩根士丹利等三家国际投资机构以认股方式向开曼公司注入约2597万美元（折合人民币约2.1亿元），取得该公司90.6%的股权和49%的投票权，所投资金经毛里求斯最终换取了大陆蒙牛乳业66.7%的股权，蒙牛乳业也变更为合资企业。 2003年，摩根士丹利等投资机构与蒙牛乳液签署了类似于国内证券市场可转债的“可换股文据”，未来换股价格仅为0.74港元／股。通过“可换股文据”向蒙牛乳业注资3523万美元，折合人民币2.9亿元。“可换股文据”实际上是股票的看涨期权。不过，这种期权价值的高低最终取决于蒙牛乳业未来的业绩。如果蒙牛乳业未来业绩好，“可换股文据”的高期权价值就可以兑现；反之，则成为废纸一张。 为了使预期增值的目标能够兑现，摩根士丹利等投资者与蒙牛管理层签署了基于业绩增长的对赌协议。双方约定，从2003年～2006年，蒙牛乳业的复合年增长率不低于50%。若达不到，公司管理层将输给摩根士丹利约6000万～7000万股的上市公司股份；如果业绩增长达到目标，摩根士丹利等机构就要拿出自己
路由基础知识 RIP路由协议入门说明(一)
路由基础知识RIP路由协议入门说明（一） 路由器的工作不外乎两个，一是路径选择，二是数据转发。进行数据转发相对容易一些，难的是如何判断到达目的网络的最佳路径。所以，路径选择就成了路由器最重要的工作。 许多路由协议可以完成路径选择的工作，常见的有RIP，OSPF，IGRP和EIGRP协议等等。这些算法中，我们不能简单的说谁好谁坏，因为算法的优劣要依据使用的环境来判断。比如RIP协议，它有时不能准确地选择最优路径，收敛的时间也略显长了一些，但对于小规模的，没有专业人员维护的网络来说，它是首选的路由协议，我们看中的是它的简单性。 如果你手头正有一个小的网络项目，那么，就让我们来安排一个计划，30分钟读完本文（一读），20分钟再细看一遍本文提及的命令和操作方法（二读），用30分钟配置网络上的所有路由器（小网络，没有几台路由器可以配的），最后20分钟，检查一下网络工作是否正常。好了，一百分钟，你的RIP网络运转起来了。就这么简单，不信，请继续往下看。 一、RIP是什么 RIP（Routing Information Protocols，路由信息协议）是使用最广泛的距离向量协议，它是由施乐（Xerox）在70年代开发的。当时，RIP是XNS （Xerox Network Service，施乐网络服务）协议簇的一部分。TCP/IP版本
的RIP是施乐协议的改进版。RIP最大的特点是，无论实现原理还是配置方法，都非常简单。 度量方法 RIP的度量是基于跳数（hops count）的，每经过一台路由器，路径的跳数加一。如此一来，跳数越多，路径就越长，RIP算法会优先选择跳数少的路径。RIP支持的最大跳数是15，跳数为16的网络被认为不可达。 路由更新 RIP中路由的更新是通过定时广播实现的。缺省情况下，路由器每隔30秒向与它相连的网络广播自己的路由表，接到广播的路由器将收到的信息添加至自身的路由表中。每个路由器都如此广播，最终网络上所有的路由器都会得知全部的路由信息。正常情况下，每30秒路由器就可以收到一次路由信息确认，如果经过180秒，即6个更新周期，一个路由项都没有得到确认，路由器就认为它已失效了。如果经过240秒，即8个更新周期，路由项仍没有得到确认，它就被从路由表中删除。上面的30秒，180秒和240秒的延时都是由计时器控制的，它们分别是更新计时器（Update Timer）、无效计时器（Invalid Timer）和刷新计时器（Flush Timer）。 路由循环
ISIS是一个分级的链接状态路由协议
ISIS是一个分级的链接状态路由协议，基于DECnet PhaseV 路由算法。ISIS可以在不同的子网上操作，包括广播型的LAN、WAN和点到点链路。ISIS是一个链接状态协议，实际上与OSPF非常相似，它也使用Hello协议寻找毗邻节点，使用一个传播协议发送链接信息。ISIS消息使用序列号，但它只是一个简单的加法计数器。当计数器计到最大值时，一个ISIS路由器没有别的选择，只能伪造一个错误触发对所有旧信息的刷新。然而，因为序列号有3 2 比特长，使得到达最大值之前有很大的序列号空间，所以这不是什么问题。但是，至少存在两个技术问题：ISIS使用一个小的度量值（6 比特），严重限制了能与它进行转换的信息；而且链接状态也只有8 比特长，路由器能通告的记录只有256个。一个非技术问题是ISIS受OSI 约束，使得与OSPF相比它的发展比较缓慢。这个限制的原因是由于SPF的要求；但现在的Wide-metric 使这个范围变成24位的扩展解决了这个问题。 一个非技术问题是ISIS受OSI约束，使得以前与OSPF相比它的发展比较缓慢。但现在的ISIS在非OSI即RFC方面（Integrated）ISIS有了很多的扩展使得他的发展比OSPF更容易实现对新的要求的支持如IPV6或者TE而且更简单易实现 一个路由器是intermediate system(IS)，一个主机就是end system(ES)，在一个主机和路由器之间运行的协议叫ES-IS，路由器与路由器之间运行的协议是IS-IS 一个subnetwork属下的接口叫：subnetwork point of attachment(SNPA)，它只是一个概念上的东西，实际上它是一个subnetwork提供的服务点，由SPNA定义的，不是实际的物理界面，SNPA的概念特性对应于子网的概念特性。 PDU：就是一个OSI层上的一个节点到它的另一端(peer)的对应层上的节点，所以一个帧也叫做Date Link PDU(DLPDU)，也因此一个网络层的packet也叫做network PDU(NPDU)，这个date unit功能类拟于OSPF的LSA，我们称它为Link State PDU(LSP)，与LSA不同的是它封装在OSPF报头之后，然后才到IP 数据包。 an LSP is itself a packet. ===================== ISIS AREAS ===================== ISIS和OSPF一样建立一个双层分级结构拓扑，但和OSPF不同的是ISIS划分area是连接中，也就是说两台路由器中间来划分area L1_Router---------|----------L2_Router 以上的竖线就是ISIS划分的area的地方，而OSPF则不是，它是在一个路由器当中划分的，一个路由器中只要有两个接口接到不同的area，这个路由器就叫做ABR area0-------ABR_Router------area1 ISIS中对路由器的称呼又和OSPF又所不同，它只有三类，一个是完全在一个area内的，OSPF叫内部路由器，ISIS叫L1，而OSPF的ABR在ISIS中叫做L1/L2，还有一类是backbone里的路由器，全都叫做L2，这样，L1/L2路由器就会维护两个line state datebase，而与ABR不同的是，L1/L2路由器不通告L2的路由给L1，因此所有的L1路由器永远不会知道area外的路由，这种情况和OSPF的tutally stubby area
对赌协议最全案例
【案例】 蒙牛——一赌成名 1999年1月，牛根生创立了“蒙牛乳业有限公司”，公司注册资本100万元。后更名为“内蒙古蒙牛乳业股份有限公司”（以下简称蒙牛乳业）。在不到三年的时间里，蒙牛迅猛发展，年销售额突破10亿元大关。快速扩张给公司带来了巨大的资金缺口，而此时，行业内的企业，伊利股份（600887）、光明乳业（600597）、三元股份（600429）先后登陆A股。在国内无法满足其融资需求的情况下，2001年底开始与摩根士丹利、鼎晖投资、英联投资等国际机构投资者接触。 2002年6月，蒙牛在英属开曼群岛和毛里求斯分别成立了一家用以承载蒙牛上市任务的壳公司。其中，开曼群岛公司由蒙牛发起人、业务联系人以及雇员等蒙牛相关人士控制。开曼群岛公司100％控股毛里求斯公司，毛里求斯公司又 通过认购蒙牛普通股等方式，获得蒙牛控股权。 毛里求斯公司认购蒙牛股份的资金，就来自上述三家机构投资者。2002年9月，三家机构投资者以认购开曼群岛公司股份的方式，注入2 597.4万美元（约2.16亿元人民币）。一年之后的2003年9月，经过内部的股权转换和计算，三家机构投资者持有开曼群岛公司49%已发行股份，剩余51%由蒙牛管理层及相关人士持有。 此间，毛里求斯公司用注入资金购得蒙牛66.7%的股份，蒙牛由此变更为外商投资企业，并成为这个上市运作系统末端的一间子公司。 2003年10月，三家机构投资者对开曼群岛公司进行了第二次注资。此番是通过认购开曼群岛公司每股面值0.001美元的可换股票据的方式，注入3 523.4万美元。这些可换股票据可以在蒙牛乳业招股完成一年后转换完毕。“可换股票据”实际上是股票的看涨期权。不过,这种期权价值的高低最终取决于蒙牛乳业未来的业绩。如果蒙牛乳业未来业绩好，“可换股文据”的高期权价值就可以兑现；反之，则成为废纸一张。为了使预期增值的目标能够兑现，摩根士丹利等投资者与蒙牛管理层签署了基于业绩增长的对赌协议。 协议约定，从2004—2006年为止的三年内，蒙牛的年复合盈利增长率如果低于50%，金牛将会转让用一定公式计算所得的某一数量股份（也可以用现金代替）予摩根士丹利、鼎晖和英联等三家机构投资者；蒙牛的年复合盈利增长率如果超过50%，摩根士丹利等三家金融机构投资者将会转让自己的相应股份给金牛，作为对给蒙牛管理层的奖励。双方规定，无论如何涉及转让的股份总共不得超过7830万股（占已发行股份的7.8%）。 2002年，中国乳制品行业年销售额复合增长率为15.5%，50%增长率的约定对蒙牛无疑是一次豪赌。 在接下来的一年时间里，蒙牛的发展状况已经远远超出了“对赌协议”预定的盈利目标。加上蒙牛历年来的表现，2005年4月6日，蒙牛发布公告称其获得摩根士丹利、鼎晖投资、英联投资和金牛的通知，摩根士丹利等三家金融机构投资者将以向金牛支付本金为598.7644万美元的可换股票据（合计可转换成6 260.8768万股蒙牛股票）的方式提前终止双方在一年前达成的估值调整机制。 目前摩根士丹利、鼎晖、英联分别持有蒙牛88万股、27万股、16万股股份，仅占总股本的0.1％。在英联、摩根士丹利、鼎晖等中后期投资者成功实现退出之后，蒙牛又顺利为自己找到了新加坡政府投资公司、美资大行Capital Group（CG）等长期接盘
对赌协议经典案例解析
对赌协议经典案例解析 对赌协议最初由国外引进，摩根士丹利等机构投资蒙牛，是对赌协议在创业型企业中应用的典型案例。 “对赌协议”也为本土投资机构所使用。2007年11月，东方富海等机构投资8000万元于无锡某太阳能公司，其中5000万元以增资方式进入公司股本，另外3000万元以委托银行贷款的方式借给企业，增资的资金直接换取企业股权，委托银行贷款的资金作为“业绩对赌”的筹码。协议约定，如果该企业完成2007、2008年预期目标，则3000万元的委托银行贷款无须归还投资人，且投资人在该企业中股权比例不变，从而令企业的估值得到提升。2007年，该公司超过预计业绩目标将近20%，并于2008年10月提前完成年度业绩目标，对赌实现双赢。 经典案例之一： 融资方：蒙牛乳业 投资方：摩根士丹利等三家国际投资机构 签订时间：2003 主要内容：2003至2006年，如果蒙牛业绩的复合增长率低于50％，以牛根生为首的蒙牛管理层要向外资方赔偿7800万股蒙牛股票，或以等值现金代价支付；反之，外方将对蒙牛股票赠予以牛根生为首的蒙牛管理团队 目前状况：已完成，蒙牛高管获得了价值数十亿元股票 1999年1月，牛根生创立了“蒙牛乳业有限公司”，公司注册资本100万元。后更名为“内蒙古蒙牛乳业股份有限公司”（以下简称“蒙牛乳业”）。2001年底摩根士丹利等机构与其接触的时候，蒙牛乳业公司成立尚不足三年，是一个比较典型的创业型企业。 2002年6月，摩根士丹利等机构投资者在开曼群岛注册了开曼公司。2002年9月，
蒙牛乳业的发起人在英属维尔京群岛注册成立了金牛公司。同日，蒙牛乳业的投资人、业务联系人和雇员注册成立了银牛公司。金牛和银牛各以1美元的价格收购了开曼群岛公司50%的股权，其后设立了开曼公司的全资子公司——毛里求斯公司。同年10月，摩根士丹利等三家国际投资机构以认股方式向开曼公司注入约2597万美元（折合人民币约2.1亿元），取得该公司90.6%的股权和49%的投票权，所投资金经毛里求斯最终换取了大陆蒙牛乳业66.7%的股权，蒙牛乳业也变更为合资企业。 2003年，摩根士丹利等投资机构与蒙牛乳业签署了类似于国内证券市场可转债的“可换股文据”，未来换股价格仅为0.74港元／股。通过“可换股文据”向蒙牛乳业注资3523万美元，折合人民币2.9亿元。“可换股文据”实际上是股票的看涨期权。不过，这种期权价值的高低最终取决于蒙牛乳业未来的业绩。如果蒙牛乳业未来业绩好，“可换股文据”的高期权价值就可以兑现；反之，则成为废纸一张。 为了使预期增值的目标能够兑现，摩根士丹利等投资者与蒙牛管理层签署了基于业绩增长的对赌协议。双方约定，从2003年～2006年，蒙牛乳业的复合年增长率不低于50%。若达不到，公司管理层将输给摩根士丹利约6000万～7000万股的上市公司股份；如果业绩增长达到目标，摩根士丹利等机构就要拿出自己的相应股份奖励给蒙牛管理层。 2004年6月，蒙牛业绩增长达到预期目标。摩根士丹利等机构“可换股文据”的期权价值得以兑现，换股时蒙牛乳业股票价格达到6港元以上；给予蒙牛乳业管理层的股份奖励也都得以兑现。摩根士丹利等机构投资者投资于蒙牛乳业的业绩对赌，让各方都成为赢家。 投资特点分析： 摩根士丹利对于蒙牛乳业基于业绩的对赌之所以能够划上圆满句号，总结归纳，该份对赌协议中有如下七个特点：一是投资方在投资以后持有企业的原始股权，如摩根士丹利等三家国际投资机构持有开曼公司90.6%的股权和49%的投票权；二是持有高杠杆性（换股价格仅为0.74港元／股）的“可换股文据”；三是高风险性（可能输给管理层几千万股股份）；四是投资方不是经营乳业，不擅长参与经营管理，仅是财务型投资；五是股份在香港证券市场流动自由；六是蒙牛乳业虽然是创业型企业，但企业管理层原来在同一类型企业工作，富有行业经验；七是所投资的企业属于日常消费品行业，周期性波动小，一旦企业形成相对优势，竞争对手难以替代，投资的行业风险小。
对赌协议问题解决之道
【案例情况】 一、金刚玻璃：最佳学习样本 （一）招股说明书披露情况 1、对赌协议缘由 公司对赌协议源自2007年一次增资扩股中引入了战略投资者，《关于公司设立以来股本演变情况专项说明》中有如下描述：2007年12月29日和2008年1月10日，公司及大股东金刚实业分别与天堂硅谷、汇众工贸和保腾创投签订《增资扩股协议》。《增资扩股协议》中附加了对赌条款，该条款约定如公司达不到协议约定的经营业绩等条件，金刚实业将向三家投资者无偿转让部分股份以予补偿。2009年1月，对赌协议签署方就有关业绩指标进行了调整。 2、对赌协议的终止 为促进本公司稳定发展，维护股权稳定，相关股东取得一致意见，重新签订《关于广东金刚玻璃科技股份有限公司的增资扩股协议之补充协议》（以下简称“增资扩股协议之补充协议（一）”）终止原《增资扩股协议》及其《补充协议书》中对赌条款。 2009年9月15日，公司、金刚实业分别与投资者重新签订《增资扩股协议之补充协议（一）》，各方一致同意终止原协议关于无偿转让股份的相关条款。 2010年4月8日，公司、金刚实业分别与三家投资者再次签订《增资扩股协议之补充协议》（以下简称“《增资扩股协议之补充协议（二）》”），各方一致同意终止原协议关于董事一票否决权的条款。被终止条款具体内容为：新公司在进行重大决策时，应由董事会形成决议而乙方推荐的董事不同意相关议案的，该议案可提交董事会讨论但不形成决议；应由股东大会形成决议而乙方推荐的董事不同意相关议案的，该议案不提交股东大会讨论。同时，《增资扩股协议之补充协议（二）》第1.2条约定：三家投资者推荐的董事、监事或高级管理人员不存在具有额外表决权的情况。
RIP路由协议详解
RIP路由协议（Routing Information Protocols，路由信息协议）是使用最广泛的距离向量协议，它是由施乐（Xerox）在70年代开发的。当时，RIP是XNS （Xerox Network Service，施乐网络服务）协议簇的一部分。TCP/IP版本的RIP是施乐协议的改进版。RIP最大的特点是，无论实现原理还是配置方法，都非常简单。 度量方法RIP的度量是基于跳数（hops count）的，每经过一台路由器，路径的跳数加一。如此一来，跳数越多，路径就越长，RIP算法会优先选择跳数少的路径。RIP支持的最大跳数是15，跳数为16的网络被认为不可达。 路由更新RIP路由协议中路由的更新是通过定时广播实现的。缺省情况下，路由器每隔30秒向与它相连的网络广播自己的路由表，接到广播的路由器将收到的信息添加至自身的路由表中。每个路由器都如此广播，最终网络上所有的路由器都会得知全部的路由信息。正常情况下，每30秒路由器就可以收到一次路由信息确认，如果经过180秒，即6个更新周期，一个路由项都没有得到确认，路由器就认为它已失效了。如果经过240秒，即8个更新周期，路由项仍没有得到确认，它就被从路由表中删除。上面的30秒，180秒和240秒的延时都是由计时器控制的，它们分别是更新计时器（_updateTimer）、无效计时器（Invalid Timer）和刷新计时器（Flush Timer）。 路由循环距离向量类的算法容易产生路由循环，RIP路由协议是距离向量算法的一种，所以它也不例外。如果网络上有路由循环，信息就会循环传递，永远不能到达目的地。为了避免这个问题，RIP等距离向量算法实现了下面4个机制。 水平分割（split horizon）。水平分割保证路由器记住每一条路由信息的来源，并且不在收到这条信息的端口上再次发送它。这是保证不产生路由循环的最基本措施。 毒性逆转（poison reverse）。当一条路径信息变为无效之后，路由器并不立即将它从路由表中删除，而是用16，即不可达的度量值将它广播出去。这样虽然增加了路由表的大小，但对消除路由循环很有帮助，它可以立即清除相邻路由器之间的任何环路。 触发更新（trigger update）。当路由表发生变化时，更新报文立即广播给相邻的所有路由器，而不是等待30秒的更新周期。同样，当一个路由器刚启动RIP 路由协议时，它广播请求报文。收到此广播的相邻路由器立即应答一个更新报文，而不必等到下一个更新周期。这样，网络拓扑的变化会最快地在网络上传播开，减少了路由循环产生的可能性。 抑制计时（holddown timer）。一条路由信息无效之后，一段时间内这条路由都处于抑制状态，即在一定时间内不再接收关于同一目的地址的路由更新。如果，路由器从一个网段上得知一条路径失效，然后，立即在另一个网段上得知这个路由有效。这个有效的信息往往是不正确的，抑制计时避免了这个问题，而且，当一条链路频繁起停时，抑制计时减少了路由的浮动，增加了网络的稳定性。 即便采用了上面的4种方法，路由循环的问题也不能完全解决，只是得到了最大程度的减少。一旦路由循环真的出现，路由项的度量值就会出现计数到无穷大（_countto Infinity）的情况。这是因为路由信息被循环传递，每传过一个路由器，度量值就加1，一直加到16，路径就成为不可达的了。RIP路由协议选择16作为不可达的度量值是很巧妙的，它既足够的大，保证了多数网络能够正常运行，又足够小，使得计数到无穷大所花费的时间最短。 邻居有些网络是NBMA（Non-Broad_cast MultiAccess，非广播多路访问）
OSPF路由协议基础 科普
OSPF路由协议基础(一) OSPF(Oｐen Short Path First)最优路径算法路由协议。ＯSＰF路由协议的Dis ｔanｃe值为11０，它拥有一个Ｍetｒｉc值,此值是OSＰF路由协议用来衡量链路好坏的,当一条链路的Metrｉc值越小，则证明此条链路越好，反之此条链路越差。 路由协议按数据传输方式分,分为有类(Claｓｓfｕll)和无类(Ｃｌassleｓs)两种，有类路由协议是指传输可达性路由信息（ＮLRI)时不带子网掩码；无类路由协议是指传输可达性路由信息(NＬＲI)时带子网掩码。路由协议按数据传输类型分, 分为距离向量(Distance Veｃｔor)和链路状态(LinｋSｔａtｅ）两种，距离向量（ＤV)路由协议没有路由器ID(Routeｒ-IＤ),并且只传递可达性路由信息(NLRI);链路状态(LS)路由协议限制每一台路由器必须要有一个未被使用过的路由器ＩＤ(Router-IＤ)，而且它无条件转发任何从邻居传来的可达性路由信息(ＮＬRＩ)。 OSPF路由协议基础（二) 距离向量路由协议： 此时，假如RouteｒA后面有一个1.0网段,RouterB后面有一个2.0网段，Rout ｅrA告诉RouterB通过我（ＲouterＡ）可以到达1.0网段，RｏuｔerＢ告诉ＲｏuｔｅrＣ通过我（RｏuterB）可以到达１.0网段，此时,RｏｕｔerA到达1.0网段的路断了,那么，他会查找它的邻居RｏutｅｒＢ,而此时RouterC也要到１．０网段，他也会去查找它的邻居RouｔerB，这时RoutｅrB的路由表里有1.0网段的路由，RouteｒA和RouteｒC都会将数据发到RouterB,可是,Rｏｕter Ｂ到不了１.０网段，这样就形成了路由环路。各种距离向量路由协议都有它自己解决路由环路的方法,在此暂不讨论。 链路状态路由协议： 在这里，我们用上面的例子继续讨论,因为在之前我曾提到过链路状态路由协议无条件转发任何从邻居传来的可达性路由信息(NLRI)，所以,RoutｅrA告诉RouteｒB我（ＲｏｕterA）可以到达１．0网段后，RoｕteｒＢ将告诉RouterC 从RｏuｔerＡ那里可到达1.0网段，RoｕterC将一个数据包发往１.0网段时,会查找路由表,得知从ＲouteｒA那里可以到达１．0网段，此时RoｕterＣ查找邻居表，得知到RoｕterA那里要经过RoｕｔｅrB，这样,数据包就可以从RouterC发到1.0网段。当RｏｕｔerA到达1.0网段的路断了,那么，因为RouterB和RouterC的路由表中都是知道通过RｏuterA才能到达1.0网段,所以，此时就不会出现路由环路。 OSPＦ路由协议基础(三) 链路状态路由协议有四种网络结构: １、有广播多层访问(Broadcａst Multi Ａcｃess)：
对赌协议的两种模式
对赌协议的两种模式 对赌协议是指收购方(投资方)与出让方(融资方)在达成并购(或者融资)协议时，在信息不对称、未来盈利不确定的情况下进行一种约定。如果约定的条件出现，投资方可以行使一种权利；如果约定的条件不出现，融资方则行使一种权利。它包括股票型对赌协议和以准时上市为目标对赌2种模式。 案例一：股票型对赌协议———关于收益率和盈利能力的对赌2011年10月，甲公司经营效益很好，且准备上市。B公司作为战略投资者，拟与甲公司的大股东C签订投资合同，其中规定：C将出售5%的普通股给B，对价为500万元，假设5%普通股数量为1000股。合同中的对赌条款约定，于2011年审计利润出来后，区分下列情况进行处理：第一，如果审计后净利润在预计利润95%之下，C 将以零对价，补充转让部分股票（根据以审计后净利润为基础的计算公式计算得出）给B。 第二，如果审计后净利润在105%预计净利润之上，B将多支付相应的对价给C（仍是根据计算公式得出，目的为B补偿C之前出售的1000股普通股价值）。 第三，如果审计后净利润在95%与105%预计净利润之间，不产生影响。 本例中对赌的主体是投资者与甲公司的股东C,因此，会计处理及其调整和变化主要是在B与C之间进行，目标公司甲的盈利能
力和净利润仅仅是调整双方股权的标准和依据。 假定投资时的净利润是5000万元，会计分录的处理是（单位为万元）：C公司的会计处理分录为（单位为万元）：借：银行存款500贷：对甲公司股权投资500 2011年，如果净利润是4500万元，少于预计利润5000万元的95%，则应该调增B的股份为（5000-4500）÷2=250股，则C会计处理分录为（单位为万元）：借：对B公司对价调整股份500（250股）贷：甲公司长期股权投资500 B公司的会计处理分录为（单位为万元）：借：甲公司长期股权投资500贷：甲公司股权投资成本款调整500案例二：以准时上市为目标对赌———达不到对赌目标则有股转换债的选择权投资方甲以600万元购买B所持C的10%股份。甲借款1900万元给C（假设期限为3年，年利率为10%）。同时投资合同规定：如B在约定时间实现IPO（假定3年），则甲将其借给C的1900万作为受让B 所持C公司10%股份的补充对价；如C不能在约定期限内实现IPO，甲可以要求B以约定价格（假设为600万元）回购甲所持的C公司的10%股份。 本案例中甲购买股权以及借款给C的交易，是一项整体交易。 国际会计准则第27号(IAS27)指出，一般将整体交易视为一项单独的交易进行处理。该交易与可转换公司债券类似，可以视为甲借款2500万元给B，同时获得转换为C上市后10%股份的权利。 因此，上述交易的处理应将2500万元全部确认为可供出售金
网络层路由协议论文.doc
计算机工程系 网络1210班（28）朱金贵 网络层安全路由协议目录 第一节网络路由协议概述 1.1路由协议概念 1.11 自治域(Autonomous System) 1.12 收敛（Convergence） 1.13 路由算法 1.2静态路由与动态路由 1.3动态路由协议的分类 第二节动态路由协议 2.1 内部网关协议（IGP，Internal Gateway Protocol） 2.11 路由信息协议RIP的优缺点及需要改进的地方 2.12放式最短路优先路由信息协议OSPF的特点和优缺点 2.13 RIP和OSPF的比较 2.2 外部网关协议（EGP，External Gateway Protocol） 2.21外部网关协议（EGP，External Gateway Protocol） 2.22边界网关协议（BGP，Border Gateway Protocol） 2.23域间路由协议（Internal Domain RoutingProtocol） 第三节心得体会 附录参考文选 第一节网络路由协议概述 1.1路由协议概念 路由协议概念：路由器必须与相邻路由器互通信息以交换路由信息，更新维护动态路由表使之正确反映网络的拓扑结构变化，并由路由器根据量度标准来决定最佳路径,路由协议是路由器之间进行通信而采用的协议，当网络启用了路由协议，网络便具有了能够自动更新路由表的强大功能。 1.11 自治域(AS,Autonomous System) 自治域(AS,Autonomous System)：由单个实体管理，具有统一管理机构、统一路由策略的网络。在这里单个实体,通常指单独的因特网服务提供者（ISP，Internet Service Provider）。 1.12 收敛（Convergence） 收敛（Convergence）：对于路由协议，网络上的路由器在一条路径不能使用时必须经历决定替代路径的
对赌协议系列案例之三
对赌协议系列案例之三 --光大创投诉任马力、武华强、武国富、 武国宏、魏建松增资扩股协议纠纷案 [案例导读] 由于在前一期关于私募股权投资公司与融资公司及控股股东签署对赌协议的合法有效性案例刊出后，受到读者的广泛关注。本文系对赌协议的系列案例之三。本文案例意在阐述投资公司与目标公司实际控制人签订对赌协议，目标公司不仅未能成功上市，反而进入破产重整程序时，股权回购的效力问题。本文内容包括裁判摘要、案件索引、审理概况、判决及理由合议庭成员。 [裁判摘要] 目标公司进入破产重整程序并不影响投资公司向目标公司实际控制人主张回购其股份。在目标公司破产清算或重整的状态下，其股权价值严重贬损。在此情形下，投资公司的投
资利益不能以持有目标公司股份或向他人转让目标公司股份实现，其依据《增资补充协议》主张目标公司实际控制人回购其股份，既符合签订案涉《增资扩股协议》、《增资补充协议》的合同目的，也不违反举轻以明重的法律原则。投资公司的法定代表人虽然系目标公司的董事，但并非目标公司的出资人，不属于《中华人民共和国破产法》第七十七条第二款规定的情形，不影响股权回购。 [案件索引] 江苏省高级人民法院（2014）苏商初字第00029号民事判决书； [案情概况] 原告光大金控创业投资有限公司，住所地在浙江省杭州市环城西路28号902室。 被告任马力、武华强、武国富、武国宏、魏建松。 原告光大金控创业投资有限公司（以下简称光大创投）诉被告任马力、武华强、武国富、武国宏、魏建松增资扩股协议
纠纷一案，本院于2014年11月13日立案受理后，依法组成合议庭，于2015年1月8日进行了庭前证据交换，并于同日公开开庭审理了本案。原告光大创投的委托代理人杨超、白麟，被告任马力、武华强、武国富、武国宏、魏建松共同的委托代理人杨勇军到庭参加诉讼。本案现已审理终结。 原告光大创投诉称：光大创投系一家在杭州注册成立的以实业投资、投资管理、投资咨询为主业的有限责任公司。光大创投于2011年12月对德勤集团股份有限公司（以下简称德勤集团）进行私募股权投资，并据此持有德勤集团4.23729%的股份。任马力、武华强、武国富、武国宏、魏建松系德勤集团的股东和实际控制人。2011年12月13日，光大创投 与其他投资方、德勤集团、任马力、武华强、武国富、武国宏、魏建松签订了《关于德勤集团股份有限公司之增资扩股协议》（以下简称《增资扩股协议》）。同日，光大创投与德 勤集团、任马力、武华强、武国富、武国宏、魏建松签订了《增资补充协议》。《增资扩股协议》3.2条约定，光大创投 同意出资人民币1.153亿元认购德勤集团新发行的1000万 股新股（对应新增注册资本1000万元），增资款项与新增注册资本之间的差额计入资本公积。《增资补充协议》6.1条约定，如果德勤集团未能在2012年12月31日前实现在境内证券交易所公开发行股票并上市，光大创投有权要求实际控