A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.
It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.
The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed.
User stories are printed or written on cards. Together developers and customers move the cards around on a large table to create a set  of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.
You may plan by time or by scope. The project velocity is  used  to  determine  either

how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). When planning by time multiply the number of iterations by the project velocity to determine how many user stories can be completed. When planning by scope divide the total weeks of estimated user stories by the project velocity to determine how many iterations till the release is ready.
Individual iterations are planned in detail just before each iteration begins and not in advance. The release planning meeting was called the planning game and the rules can be found at the Portland Pattern Repository.
When the final release plan is created and is displeasing to management it is tempting to just change the estimates for the user stories. You must not do this. The estimates are valid and will be required as-is during the iteration planning meetings. Underestimating now will cause problems later. Instead negotiate an acceptable release plan. Negotiate until the developers, customers, and managers can all agree to the release plan.
The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to  be  done.  Resources  are  how  many

people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.
No one can control all 4 variables.  When you change one you inadvertently cause another to change in response.  Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables that may not become obvious until your project slows to a crawl just before the deadline. 
In essence there are only 3 variables that you actually want to change. Management can set 2 of those variables and the third will be set by the development team.  Also let the developers moderate the customers desire to have the project done immediately by hiring too many people at one time.