 TCP sessions to dis- tribute label requests. Security: Once the path has been established and the data is being forwarded, the frame is no longer visible to the management or control plane software at the upper layers of the network. There is minimal chance that unauthorized individuals will be able to sniff or ruin the data or even redirect them toward an unintended destination. Data is only allowed to enter and exit the GLSP at locations authorized and configured by the control plane. Both CR-LDP and RSVP-TE have the support of MD5 signature pass- word and authentication. CR-LDP uses TCP/IP services, which is vulnerable to denial of service attacks; therefore, any in-between errors are reported immediately. RSVP-TE uses UDP services and the IETF standard to specify an authentication and policy control. This allows the originator of the messages to be verified (e.g., using MD5) and makes it possible to police unauthorized or malicious reservation of resources. Similar features could be defined for CR-LDP but the connection-oriented nature of the TCP ses- sion makes this less important. 8.3.2.6.1 Protocol Type RSVP-TE is a soft state protocol. After initial GLSP setup process, refresh messages must be periodically exchanged to notify the peers that the connection is still desired. State refreshes help to make sure that GLSP state is properly synchronized between adjacent nodes, procedure that is required by the fact that RSVP-TE uses IP datagrams, SO that con- trol messages may be lost without notification. Periodic refresh messages imply the refresh overhead: this is a sort of weakness in the protocol that makes a bit more difficult to scale it to large networks. A proposed solution to reduce the refresh messages number and the bandwidth they require from the control plane communication structure is bundling many refresh messages together. This reduces the traffic volume but the processing time is still the same. CR-LDP is referred to as a hard state protocol. This means that all the information is exchanged at