Multiplex communications – Communication techniques for information carried in plural... – Adaptive
Reexamination Certificate
1999-01-11
2002-11-26
Vincent, David (Department: 2732)
Multiplex communications
Communication techniques for information carried in plural...
Adaptive
C370S230000
Reexamination Certificate
active
06487218
ABSTRACT:
TECHNOLOGICAL BACKGROUND
The present invention relates to a communication device and method used for configuring a link, preferably one that accesses a communication network that operates by exchanging packets. An example of such a communication network is the internet.
The internet is a network of computers, where communication is conducted by means of units referred to as “packets”. This means that the information to be transmitted is distributed over such packets, and these packets can be sent individually and independently over the network. This communication is governed by a protocol, in this case the so-called internet protocol IP. A protocol is a set of rules that determines the format and the general communication procedure, so that each member of the network must conform to the protocol in order to be able to communicate with the other members.
There are different possibilities of accessing the internet. The most basic is via a dedicated line, i.e. a line that is constantly connected to another computer that is a part of the network. The computer accessing the network via a dedicated line thereby becomes a member of the network, i.e. the network is thereby extended. The communication along the line is conducted in accordance with the IP. However, a dedicated line is expensive, so that such an arrangement only makes sense for a user requiring permanent access to the internet and/or the quick transmitting of large data amounts.
An alternative to a dedicated line is a pseudo-dedicated connection that is only established if a connection to the internet is required, but then acts just like a dedicated line. A typical example of such a connection is a modem link from a single user to a server in the internet, such as a university computer or commercial internet access server. The user only establishes a connection to the internet when necessary, so that the high costs entailed by a dedicated line are not incurred, but the established connection lets the user become a full member of the internet, because the connection then acts like a dedicated line.
Such a pseudo-dedicated connection between two points (the computer wishing to temporarily access the internet on the one hand, and the server in the internet that is typically connected to a plurality of other internet members on the other) requires its own protocol. Two known protocols are SLIP (Serial Line Internet Protocol) and PPP (Point to Point Protocol). In recent years, PPP has become the dominant protocol for such pseudo-dedicated connections.
PPP is defined in the Networking Group RfC (Request for Comments) 1661, editor W. Simpson, July 1994. PPP is comprised of three main components: a method of encapsulating multi-protocol datagrams, a datagram being a unit of transmission in the network layer (such as IP), a ink control protocol (LCP) for establishing, configuring and testing the data-link connection, and a family of network control protocols (NCP) for establishing and configuring different network-layer protocols. The Point-to-Point Protocol is designed to transport packets between two so-called peers, i.e. the two ends of a link conforming to the protocol. These links provide full-duplex simultaneous bi-directional operation.
The communication across the link established by PPP is accomplished such that a datagram, i.e. the unit of transmission in the network layer, such as IP, is encapsulated into one or more frames and passed to the data link layer. The unit of transmission on the data link layer is a frame, where said frame may include a header and/or a trailer, along with some number of units of data. Usually, a packet is mapped to a frame.
The LCP is used to agree upon the encapsulation format options, handle varying limits on sizes of packets, detect configuration errors, and terminate the link. Other optional facilities are the authentication of the identity of its peer on the link, and the determination when a link is functioning properly and when it is failing.
FIG. 2
shows a PPP encapsulation in accordance with RfC 1661. Reference numeral
1
indicates a protocol field,
2
an information field, and
3
a padding field. These fields are transmitted in an order from left to right.
The protocol field
1
is one or two octets (an octet is another expression for an 8-bit byte), and its value identifies the datagram encapsulated in the information field 2 of the packet. Protocol field values in the “10***” to “3***” range identify the network-layer protocol for specific packets, and values in the “8***” to “b***” range identify packets belonging to the associated NCPs, if any. Protocol field values in the “4***” to “7***” range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the “c***” to “f***” range identify packets as link-layer control protocols , such as LCP. RfC 1661 makes the following reservations for said values:
TABLE 1
Value (in hex)
Protocol Name
0001
Padding Protocol
0003 to 001f
reserved (transparency inefficient)
007d
reserved (Control Escape)
00cf
reserved (PPP NLPID)
00ff
reserved (compression inefficient)
8001 to 801f
unused
807d
unused
80cf
unused
80ff
unused
c021
Link Control Protocol
c023
Password Authentication Protocol
c025
Link Quality Report
c223
Challenge Handshake Authentication Protocol
The information field is 0 or more octets. The information field contains the datagram for the protocol specified in the protocol field. The maximum length for the information field is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets or bytes, including the padding. By negotiating, consenting PPP implementations may use other values for the MRU.
Finally, the information field may be padded with an arbitrary number of octets up to the MRU. This padding is contained in the padding field and it is the responsibility of each protocol to distinguish between padding octets and real information.
In accordance with RfC 1661, in order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. This is an absolute requirement. After the link has been established, the peer may be authenticated, i.e. this is an option. Then, PPP must send NCP packets to choose and configure one or more network-layer protocols, i.e. this is again an absolute requirement. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communication until explicit LCP packets close the link down, or until some external event occurs (e.g. an inactivity timer expires).
It should be remarked that there are three basic answers for a peer to send out in response to the receipt of a configure request packet over the link: sending an ACK packet (acknowledged), e.g. to indicate that a setting proposed in the received packet is accepted, sending a NACK packet (not acknowledged), e.g. to indicate that a proposed setting is not accepted, or sending a reject packet, to thereby indicate that the received packet cannot be accepted, e.g. because it has the wrong syntax. The peer can also react to the receipt of a packet by discarding it without sending out a reject packet. This is consequently referred to as “silent” discarding.
As already mentioned, the Link Control Protocol (LCP) is used to establish the connection through an exchange of configure packets. This exchange is complete, and the LCP opened state entered, once a configure ACK (acknowledgment) packet has been both sent and received. During this so-called link establishment phase, only LCP packets are processed and any non-LCP packets are necessarily discarded without processing.
After the link establishment phase, an authentication phase may follow, i.e. is optional. However, if an implementation desires that the peer authenticate with some specific authentication protocol, then it necessarily must request the use of that authentication protocol during the link establishment phase. Another phase that can follow th
Gerdes Martin
Ludwig Reiner
Telefonaktiebolaget LM Ericsson
Vincent David
LandOfFree
Method and device for configuring a link does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device for configuring a link, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for configuring a link will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2943796